<!doctype html><html lang="en">
 <head>
  <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport">
  <title>P2459R0: 2022 January Library Evolution Poll Outcomes</title>
<style data-fill-with="stylesheet">/******************************************************************************
 *                   Style sheet for the W3C specifications                   *
 *
 * Special classes handled by this style sheet include:
 *
 * Indices
 *   - .toc for the Table of Contents (<ol class="toc">)
 *     + <span class="secno"> for the section numbers
 *   - #toc for the Table of Contents (<nav id="toc">)
 *   - ul.index for Indices (<a href="#ref">term</a><span>, in § N.M</span>)
 *   - table.index for Index Tables (e.g. for properties or elements)
 *
 * Structural Markup
 *   - table.data for general data tables
 *     -> use 'scope' attribute, <colgroup>, <thead>, and <tbody> for best results !
 *     -> use <table class='complex data'> for extra-complex tables
 *     -> use <td class='long'> for paragraph-length cell content
 *     -> use <td class='pre'> when manual line breaks/indentation would help readability
 *   - dl.switch for switch statements
 *   - ol.algorithm for algorithms (helps to visualize nesting)
 *   - .figure and .caption (HTML4) and figure and figcaption (HTML5)
 *     -> .sidefigure for right-floated figures
 *   - ins/del
 *     -> ins/del.c### for candidate and proposed changes (amendments)
 *
 * Code
 *   - pre and code
 *
 * Special Sections
 *   - .note       for informative notes             (div, p, span, aside, details)
 *   - .example    for informative examples          (div, p, pre, span)
 *   - .issue      for issues                        (div, p, span)
 *   - .advisement for loud normative statements     (div, p, strong)
 *   - .annoying-warning for spec obsoletion notices (div, aside, details)
 *   - .correction for "candidate corrections"       (div, aside, details, section)
 *   - .addition   for "candidate additions"         (div, aside, details, section)
 *   - .correction.proposed for "proposed corrections" (div, aside, details, section)
 *   - .addition.proposed   for "proposed additions"   (div, aside, details, section)
 *
 * Definition Boxes
 *   - pre.def   for WebIDL definitions
 *   - table.def for tables that define other entities (e.g. CSS properties)
 *   - dl.def    for definition lists that define other entitles (e.g. HTML elements)
 *
 * Numbering
 *   - .secno for section numbers in .toc and headings (<span class='secno'>3.2</span>)
 *   - .marker for source-inserted example/figure/issue numbers (<span class='marker'>Issue 4</span>)
 *   - ::before styled for CSS-generated issue/example/figure numbers:
 *     -> Documents wishing to use this only need to add
 *        figcaption::before,
 *        .caption::before { content: "Figure "  counter(figure) " ";  }
 *        .example::before { content: "Example " counter(example) " "; }
 *        .issue::before   { content: "Issue "   counter(issue) " ";   }
 *
 * Header Stuff (ignore, just don't conflict with these classes)
 *   - .head for the header
 *   - .copyright for the copyright
 *
 * Outdated warning for old specs
 *
 * Miscellaneous
 *   - .overlarge for things that should be as wide as possible, even if
 *     that overflows the body text area. This can be used on an item or
 *     on its container, depending on the effect desired.
 *     Note that this styling basically doesn't help at all when printing,
 *     since A4 paper isn't much wider than the max-width here.
 *     It's better to design things to fit into a narrower measure if possible.
 *
 *   - js-added ToC jump links (see fixup.js)
 *
 ******************************************************************************/

/* color variables included separately for reliability */

/******************************************************************************/
/*                                    Body                                    */
/******************************************************************************/

	html {
	}

	body {
		counter-reset: example figure issue;

		/* Layout */
		max-width: 50em;			  /* limit line length to 50em for readability   */
		margin: 0 auto;				/* center text within page                    */
		padding: 1.6em 1.5em 2em 50px; /* assume 16px font size for downlevel clients */
		padding: 1.6em 1.5em 2em calc(26px + 1.5em); /* leave space for status flag    */

		/* Typography */
		line-height: 1.5;
		font-family: sans-serif;
		widows: 2;
		orphans: 2;
		word-wrap: break-word;
		overflow-wrap: break-word;
		hyphens: auto;

		color: black;
		color: var(--text);
		background: white top left fixed no-repeat;
		background: var(--bg) top left fixed no-repeat;
		background-size: 25px auto;
	}


/******************************************************************************/
/*                         Front Matter & Navigation                          */
/******************************************************************************/

/** Header ********************************************************************/

	div.head { margin-bottom: 1em; }
	div.head hr { border-style: solid; }

	div.head h1 {
		font-weight: bold;
		margin: 0 0 .1em;
		font-size: 220%;
	}

	div.head h2 { margin-bottom: 1.5em;}

/** W3C Logo ******************************************************************/

	.head .logo {
		float: right;
		margin: 0.4rem 0 0.2rem .4rem;
	}

	.head img[src*="logos/W3C"] {
		display: block;
		border: solid #1a5e9a;
		border: solid var(--logo-bg);
		border-width: .65rem .7rem .6rem;
		border-radius: .4rem;
		background: #1a5e9a;
		background: var(--logo-bg);
		color: white;
		color: var(--logo-text);
		font-weight: bold;
	}

	.head a:hover > img[src*="logos/W3C"],
	.head a:focus > img[src*="logos/W3C"] {
		opacity: .8;
	}

	.head a:active > img[src*="logos/W3C"] {
		background: #c00;
		background: var(--logo-active-bg);
		border-color: #c00;
		border-color: var(--logo-active-bg);
	}

	/* see also additional rules in Link Styling section */

/** Copyright *****************************************************************/

	p.copyright,
	p.copyright small { font-size: small; }

/** Back to Top / ToC Toggle **************************************************/

	@media print {
		#toc-nav {
			display: none;
		}
	}
	@media not print {
		#toc-nav {
			position: fixed;
			z-index: 3;
			bottom: 0; left: 0;
			margin: 0;
			min-width: 1.33em;
			border-top-right-radius: 2rem;
			box-shadow: 0 0 2px;
			font-size: 1.5em;
		}
		#toc-nav > a {
			display: block;
			white-space: nowrap;

			height: 1.33em;
			padding: .1em 0.3em;
			margin: 0;

			box-shadow: 0 0 2px;
			border: none;
			border-top-right-radius: 1.33em;

			color: #707070;
			color: var(--tocnav-normal-text);
			background: white;
			background: var(--tocnav-normal-bg);
		}
		#toc-nav > a:hover,
		#toc-nav > a:focus {
			color: black;
			color: var(--tocnav-hover-text);
			background: #f8f8f8;
			background: var(--tocnav-hover-bg);
		}
		#toc-nav > a:active {
			color: #c00;
			color: var(--tocnav-active-text);
			background: white;
			background: var(--tocnav-active-bg);
		}

		#toc-nav > #toc-jump {
			padding-bottom: 2em;
			margin-bottom: -1.9em;
		}

		/* statusbar gets in the way on keyboard focus; remove once browsers fix */
		#toc-nav > a[href="#toc"]:not(:hover):focus:last-child {
			padding-bottom: 1.5rem;
		}

		#toc-nav:not(:hover) > a:not(:focus) > span + span {
			/* Ideally this uses :focus-within on #toc-nav */
			display: none;
		}
		#toc-nav > a > span + span {
			padding-right: 0.2em;
		}
	}

/** ToC Sidebar ***************************************************************/

	/* Floating sidebar */
	@media screen {
		body.toc-sidebar #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			max-width: 80%;
			max-width: calc(100% - 2em - 26px);
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			color: black;
			color: var(--tocsidebar-text);
			background: inherit;
			background-color: #f7f8f9;
			background-color: var(--tocsidebar-bg);
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
			box-shadow: -.1em 0 .25em var(--tocsidebar-shadow) inset;
		}
		body.toc-sidebar #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
			color: var(--tocsidebar-heading-text);
		}
		body.toc-sidebar #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	/* Hide main scroller when only the ToC is visible anyway */
	@media screen and (max-width: 28em) {
		body.toc-sidebar {
			overflow: hidden;
		}
	}

	/* Sidebar with its own space */
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			color: black;
			color: var(--tocsidebar-text);
			background: inherit;
			background-color: #f7f8f9;
			background-color: var(--tocsidebar-bg);
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
			box-shadow: -.1em 0 .25em var(--tocsidebar-shadow) inset;
		}
		body:not(.toc-inline) #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
			color: var(--tocsidebar-heading-text);
		}

		body:not(.toc-inline) {
			padding-left: 29em;
		}
		/* See also Overflow section at the bottom */

		body:not(.toc-inline) #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) {
			margin: 0 4em;
		}
	}

/******************************************************************************/
/*                                Sectioning                                  */
/******************************************************************************/

/** Headings ******************************************************************/

	h1, h2, h3, h4, h5, h6, dt {
		page-break-after: avoid;
		page-break-inside: avoid;
		font: 100% sans-serif;   /* Reset all font styling to clear out UA styles */
		font-family: inherit;	/* Inherit the font family. */
		line-height: 1.2;		/* Keep wrapped headings compact */
		hyphens: manual;		/* Hyphenated headings look weird */
	}

	h2, h3, h4, h5, h6 {
		margin-top: 3rem;
	}

	h1, h2, h3 {
		color: #005A9C;
		color: var(--heading-text);
	}

	h1 { font-size: 170%; }
	h2 { font-size: 140%; }
	h3 { font-size: 120%; }
	h4 { font-weight: bold; }
	h5 { font-style: italic; }
	h6 { font-variant: small-caps; }
	dt { font-weight: bold; }

/** Subheadings ***************************************************************/

	h1 + h2,
	#profile-and-date {
		/* #profile-and-date is a subtitle in an H2 under the H1 */
		margin-top: 0;
	}
	h2 + h3,
	h3 + h4,
	h4 + h5,
	h5 + h6 {
		margin-top: 1.2em; /* = 1 x line-height */
	}

/** Section divider ***********************************************************/

	:not(.head) > :not(.head) + hr {
		font-size: 1.5em;
		text-align: center;
		margin: 1em auto;
		height: auto;
		color: black;
		color: var(--hr-text);
		border: transparent solid 0;
		background: transparent;
	}
	:not(.head) > hr::before {
		content: "\2727\2003\2003\2727\2003\2003\2727";
	}

/******************************************************************************/
/*                            Paragraphs and Lists                            */
/******************************************************************************/

	p {
		margin: 1em 0;
	}

	dd > p:first-child,
	li > p:first-child {
		margin-top: 0;
	}

	ul, ol {
		margin-left: 0;
		padding-left: 2em;
	}

	li {
		margin: 0.25em 0 0.5em;
		padding: 0;
	}

	dl dd {
		margin: 0 0 .5em 2em;
	}

	.head dd + dd { /* compact for header */
		margin-top: -.5em;
	}

	/* Style for algorithms */
	ol.algorithm ol:not(.algorithm),
	.algorithm > ol ol:not(.algorithm) {
	border-left: 0.5em solid #DEF;
	border-left: 0.5em solid var(--algo-border);
	}

	/* Put nice boxes around each algorithm. */
	[data-algorithm]:not(.heading) {
	 padding: .5em;
	 border: thin solid #ddd;
	 border: thin solid var(--algo-border);
	 border-radius: .5em;
	 margin: .5em calc(-0.5em - 1px);
	}
	[data-algorithm]:not(.heading) > :first-child {
	 margin-top: 0;
	}
	[data-algorithm]:not(.heading) > :last-child {
	 margin-bottom: 0;
	}

	/* Style for switch/case <dl>s */
	dl.switch > dd > ol.only,
	dl.switch > dd > .only > ol {
	margin-left: 0;
	}
	dl.switch > dd > ol.algorithm,
	dl.switch > dd > .algorithm > ol {
	margin-left: -2em;
	}
	dl.switch {
	padding-left: 2em;
	}
	dl.switch > dt {
	text-indent: -1.5em;
	margin-top: 1em;
	}
	dl.switch > dt + dt {
	margin-top: 0;
	}
	dl.switch > dt::before {
	content: '\21AA';
	padding: 0 0.5em 0 0;
	display: inline-block;
	width: 1em;
	text-align: right;
	line-height: 0.5em;
	}

/** Terminology Markup ********************************************************/


/******************************************************************************/
/*                                 Inline Markup                              */
/******************************************************************************/

/** Terminology Markup ********************************************************/
	dfn   { /* Defining instance */
		font-weight: bolder;
	}
	a > i { /* Instance of term */
		font-style: normal;
	}
	dt dfn code, code.idl {
		font-size: inherit;
	}
	dfn var {
		font-style: normal;
	}

/** Change Marking ************************************************************/

	del {
		color: #aa0000;
		color: var(--del-text);
		background: transparent;
		background: var(--del-bg);
		text-decoration: line-through;
	}
	ins {
		color: #006100;
		color: var(--ins-text);
		background: transparent;
		background: var(--ins-bg);
		text-decoration: underline;
	}

	/* for amendments (candidate/proposed changes) */

	.amendment ins, .correction ins, .addition ins,
	ins[class^=c] {
		text-decoration-style: dotted;
	}
	.amendment del, .correction del, .addition del,
	del[class^=c] {
		text-decoration-style: dotted;
	}
	.amendment.proposed ins, .correction.proposed ins, .addition.proposed ins,
	ins[class^=c].proposed {
		text-decoration-style: double;
	}
	.amendment.proposed del, .correction.proposed del, .addition.proposed del,
	del[class^=c].proposed {
		text-decoration-style: double;
	}

/** Miscellaneous improvements to inline formatting ***************************/

	sup {
		vertical-align: super;
		font-size: 80%
	}

/******************************************************************************/
/*                                    Code                                    */
/******************************************************************************/

/** General monospace/pre rules ***********************************************/

	pre, code, samp {
		font-family: Menlo, Consolas, "DejaVu Sans Mono", Monaco, monospace;
		font-size: .9em;
		hyphens: none;
		text-transform: none;
		text-align: left;
		text-align: start;
		font-variant: normal;
		orphans: 3;
		widows: 3;
		page-break-before: avoid;
	}
	pre code,
	code code {
		font-size: 100%;
	}

	pre {
		margin-top: 1em;
		margin-bottom: 1em;
		overflow: auto;
	}

/** Inline Code fragments *****************************************************/

	/* Do something nice. */

/******************************************************************************/
/*                                    Links                                   */
/******************************************************************************/

/** General Hyperlinks ********************************************************/

	/* We hyperlink a lot, so make it less intrusive */
	a[href] {
		color: #034575;
		color: var(--a-normal-text);
		text-decoration: underline #707070;
		text-decoration: underline var(--a-normal-underline);
		text-decoration-skip-ink: none;
	}
	a:visited {
		color: #034575;
		color: var(--a-visited-text);
		text-decoration-color: #bbb;
		text-decoration-color: var(--a-visited-underline);
	}

	/* Indicate interaction with the link */
	a[href]:focus,
	a[href]:hover {
		text-decoration-thickness: 2px;
	}
	a[href]:active {
		color: #c00;
		color: var(--a-active-text);
		text-decoration-color: #c00;
		text-decoration-color: var(--a-active-underline);
	}

	/* Backout above styling for W3C logo */
	.head .logo,
	.head .logo a {
		border: none;
		text-decoration: none;
		background: transparent;
	}

/******************************************************************************/
/*                                    Images                                  */
/******************************************************************************/

	img {
		border-style: none;
	}

	img, svg {
		/* Intentionally not color-scheme aware. */
		background: white;
	}

	/* For autogen numbers, add
	  .caption::before, figcaption::before { content: "Figure " counter(figure) ". "; }
	*/

	figure, .figure, .sidefigure {
		page-break-inside: avoid;
		text-align: center;
		margin: 2.5em 0;
	}
	.figure img,	.sidefigure img,	figure img,
	.figure object, .sidefigure object, figure object {
		max-width: 100%;
		margin: auto;
		height: auto;
	}
	.figure pre, .sidefigure pre, figure pre {
		text-align: left;
		display: table;
		margin: 1em auto;
	}
	.figure table, figure table {
		margin: auto;
	}
	@media screen and (min-width: 20em) {
		.sidefigure {
			float: right;
			width: 50%;
			margin: 0 0 0.5em 0.5em;
		}
	}
	.caption, figcaption, caption {
		font-style: italic;
		font-size: 90%;
	}
	.caption::before, figcaption::before, figcaption > .marker {
		font-weight: bold;
	}
	.caption, figcaption {
		counter-increment: figure;
	}

	/* DL list is indented 2em, but figure inside it is not */
	dd > .figure, dd > figure { margin-left: -2em; }

/******************************************************************************/
/*                             Colored Boxes                                  */
/******************************************************************************/

	.issue, .note, .example, .assertion, .advisement, blockquote,
	.amendment, .correction, .addition {
		margin: 1em auto;
		padding: .5em;
		border: .5em;
		border-left-style: solid;
		page-break-inside: avoid;
	}
	span.issue, span.note {
		padding: .1em .5em .15em;
		border-right-style: solid;
	}

	blockquote > :first-child,
	.note  > p:first-child,
	.issue > p:first-child,
	.amendment > p:first-child,
	.correction > p:first-child,
	.addition > p:first-child {
		margin-top: 0;
	}
	blockquote > :last-child,
	.note  > p:last-child,
	.issue > p:last-child,
	.amendment > p:last-child,
	.correction > p:last-child,
	.addition > p:last-child {
		margin-bottom: 0;
	}


	.issue::before, .issue > .marker,
	.example::before, .example > .marker,
	.note::before, .note > .marker,
	details.note > summary > .marker,
	.amendment::before, .amendment > .marker,
	details.amendment > summary > .marker,
	.addition::before, .addition > .marker,
	addition.amendment > summary > .marker,
	.correction::before, .correction > .marker,
	correction.amendment > summary > .marker
	{
		text-transform: uppercase;
		padding-right: 1em;
	}

	.example::before, .example > .marker {
		display: block;
		padding-right: 0em;
	}

/** Blockquotes ***************************************************************/

	blockquote {
		border-color: silver;
		border-color: var(--blockquote-border);
		background: transparent;
		background: var(--blockquote-bg);
		color: currentcolor;
		color: var(--blockquote-text);
	}

/** Open issue ****************************************************************/

	.issue {
		border-color: #e05252;
		border-color: var(--issue-border);
		background: #fbe9e9;
		background: var(--issue-bg);
		color: black;
		color: var(--issue-text);
		counter-increment: issue;
		overflow: auto;
	}
	.issue::before, .issue > .marker {
		color: #831616;
		color: var(--issueheading-text);
	}
	/* Add .issue::before { content: "Issue " counter(issue) " "; } for autogen numbers,
	  or use class="marker" to mark up the issue number in source. */

/** Example *******************************************************************/

	.example {
		border-color: #e0cb52;
		border-color: var(--example-border);
		background: #fcfaee;
		background: var(--example-bg);
		color: black;
		color: var(--example-text);
		counter-increment: example;
		overflow: auto;
		clear: both;
	}
	.example::before, .example > .marker {
		color: #574b0f;
		color: var(--exampleheading-text);
	}
	/* Add .example::before { content: "Example " counter(example) " "; } for autogen numbers,
	  or use class="marker" to mark up the example number in source. */

/** Non-normative Note ********************************************************/

	.note {
		border-color: #52e052;
		border-color: var(--note-border);
		background: #e9fbe9;
		background: var(--note-bg);
		color: black;
		color: var(--note-text);
		overflow: auto;
	}

	.note::before, .note > .marker,
	details.note > summary {
		color: hsl(120, 70%, 30%);
		color: var(--noteheading-text);
	}
	/* Add .note::before { content: "Note "; } for autogen label,
	  or use class="marker" to mark up the label in source. */

	details.note[open] > summary {
		border-bottom: 1px silver solid;
		border-bottom: 1px var(--notesummary-underline) solid;
	}

/** Assertion Box *************************************************************/
	/*  for assertions in algorithms */

	.assertion {
		border-color: #AAA;
		border-color: var(--assertion-border);
		background: #EEE;
		background: var(--assertion-bg);
		color: black;
		color: var(--assertion-text);
	}

/** Advisement Box ************************************************************/
	/*  for attention-grabbing normative statements */

	.advisement {
		border-color: orange;
		border-color: var(--advisement-border);
		border-style: none solid;
		background: #fec;
		background: var(--advisement-bg);
		color: black;
		color: var(--advisement-text);
	}
	strong.advisement {
		display: block;
		text-align: center;
	}
	.advisement::before, .advisement > .marker {
		color: #b35f00;
		color: var(--advisementheading-text);
	}

/** Amendment Box *************************************************************/

	.amendment, .correction, .addition {
		border-color: #330099;
		border-color: var(--amendment-border);
		background: #F5F0FF;
		background: var(--amendment-bg);
		color: black;
		color: var(--amendment-text);
	}
	.amendment.proposed, .correction.proposed, .addition.proposed {
		border-style: solid;
		border-block-width: 0.25em;
	}
	.amendment::before, .amendment > .marker,
	details.amendment > summary::before, details.amendment > summary > .marker,
	.correction::before, .correction > .marker,
	details.correction > summary::before, details.correction > summary > .marker,
	.addition::before, .addition > .marker,
	details.addition > summary::before, details.addition > summary > .marker {
		color: #220066;
		color: var(--amendmentheading-text);
	}
	.amendment.proposed::before, .amendment.proposed > .marker,
	details.amendment.proposed > summary::before, details.amendment.proposed > summary > .marker,
	.correction.proposed::before, .correction.proposed > .marker,
	details.correction.proposed > summary::before, details.correction.proposed > summary > .marker,
	.addition.proposed::before, .addition.proposed > .marker,
	details.addition.proposed > summary::before, details.addition.proposed > summary > .marker {
		font-weight: bold;
	}

/** Spec Obsoletion Notice ****************************************************/
	/* obnoxious obsoletion notice for older/abandoned specs. */

	details {
		display: block;
	}
	summary {
		font-weight: bolder;
	}

	.annoying-warning:not(details),
	details.annoying-warning:not([open]) > summary,
	details.annoying-warning[open] {
		background: hsla(40,100%,50%,0.95);
		background: var(--warning-bg);
		color: black;
		color: var(--warning-text);
		padding: .75em 1em;
		border: red;
		border: var(--warning-border);
		border-style: solid none;
		box-shadow: 0 2px 8px black;
		text-align: center;
	}
	.annoying-warning :last-child {
		margin-bottom: 0;
	}

@media not print {
	details.annoying-warning[open] {
		position: fixed;
		left: 0;
		right: 0;
		bottom: 2em;
		z-index: 1000;
	}
}

	details.annoying-warning:not([open]) > summary {
		text-align: center;
	}

/** Entity Definition Boxes ***************************************************/

	.def {
		padding: .5em 1em;
		background: #def;
		background: var(--def-bg);
		margin: 1.2em 0;
		border-left: 0.5em solid #8ccbf2;
		border-left: 0.5em solid var(--def-border);
		color: black;
		color: var(--def-text);
	}

/******************************************************************************/
/*                                    Tables                                  */
/******************************************************************************/

	th, td {
		text-align: left;
		text-align: start;
	}

/** Property/Descriptor Definition Tables *************************************/

	table.def {
		/* inherits .def box styling, see above */
		width: 100%;
		border-spacing: 0;
	}

	table.def td,
	table.def th {
		padding: 0.5em;
		vertical-align: baseline;
		border-bottom: 1px solid #bbd7e9;
		border-bottom: 1px solid var(--defrow-border);
	}

	table.def > tbody > tr:last-child th,
	table.def > tbody > tr:last-child td {
		border-bottom: 0;
	}

	table.def th {
		font-style: italic;
		font-weight: normal;
		padding-left: 1em;
		width: 3em;
	}

	/* For when values are extra-complex and need formatting for readability */
	table td.pre {
		white-space: pre-wrap;
	}

	/* A footnote at the bottom of a def table */
	table.def td.footnote {
		padding-top: 0.6em;
	}
	table.def td.footnote::before {
		content: " ";
		display: block;
		height: 0.6em;
		width: 4em;
		border-top: thin solid;
	}

/** Data tables (and properly marked-up index tables) *************************/
	/*
		<table class="data"> highlights structural relationships in a table
		when correct markup is used (e.g. thead/tbody, th vs. td, scope attribute)

		Use class="complex data" for particularly complicated tables --
		(This will draw more lines: busier, but clearer.)

		Use class="long" on table cells with paragraph-like contents
		(This will adjust text alignment accordingly.)
		Alternately use class="longlastcol" on tables, to have the last column assume "long".
	*/

	table {
		word-wrap: normal;
		overflow-wrap: normal;
		hyphens: manual;
	}

	table.data,
	table.index {
		margin: 1em auto;
		border-collapse: collapse;
		border: hidden;
		width: 100%;
	}
	table.data caption,
	table.index caption {
		max-width: 50em;
		margin: 0 auto 1em;
	}

	table.data td,  table.data th,
	table.index td, table.index th {
		padding: 0.5em 1em;
		border-width: 1px;
		border-color: silver;
		border-color: var(--datacell-border);
		border-top-style: solid;
	}

	table.data thead td:empty {
		padding: 0;
		border: 0;
	}

	table.data  thead,
	table.index thead,
	table.data  tbody,
	table.index tbody {
		border-bottom: 2px solid;
	}

	table.data colgroup,
	table.index colgroup {
		border-left: 2px solid;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		border-right: 2px solid;
		border-top: 1px solid silver;
		border-top: 1px solid var(--datacell-border);
		padding-right: 1em;
	}

	table.data th[colspan],
	table.data td[colspan] {
		text-align: center;
	}

	table.complex.data th,
	table.complex.data td {
		border: 1px solid silver;
		border: 1px solid var(--datacell-border);
		text-align: center;
	}

	table.data.longlastcol td:last-child,
	table.data td.long {
		vertical-align: baseline;
		text-align: left;
	}

	table.data img {
		vertical-align: middle;
	}


/*
Alternate table alignment rules

	table.data,
	table.index {
		text-align: center;
	}

	table.data  thead th[scope="row"],
	table.index thead th[scope="row"] {
		text-align: right;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		text-align: right;
	}

Possible extra rowspan handling

	table.data  tbody th[rowspan]:not([rowspan='1']),
	table.index tbody th[rowspan]:not([rowspan='1']),
	table.data  tbody td[rowspan]:not([rowspan='1']),
	table.index tbody td[rowspan]:not([rowspan='1']) {
		border-left: 1px solid silver;
	}

	table.data  tbody th[rowspan]:first-child,
	table.index tbody th[rowspan]:first-child,
	table.data  tbody td[rowspan]:first-child,
	table.index tbody td[rowspan]:first-child{
		border-left: 0;
		border-right: 1px solid silver;
	}
*/

/******************************************************************************/
/*                                  Indices                                   */
/******************************************************************************/


/** Table of Contents *********************************************************/

	.toc a {
		/* More spacing; use padding to make it part of the click target. */
		padding: 0.1rem 1px 0;
		/* Larger, more consistently-sized click target */
		display: block;
		/* Switch to using border-bottom for underlines */
		text-decoration: none;
		border-bottom: 1px solid;
		/* Reverse color scheme */
		color: black;
		color: var(--toclink-text);
		border-color: #3980b5;
		border-color: var(--toclink-underline);
	}
	.toc a:visited {
		color: black;
		color: var(--toclink-visited-text);
		border-color: #054572;
		border-color: var(--toclink-visited-underline);
	}
	.toc a:focus,
	.toc a:hover {
		background: rgba(75%, 75%, 75%, .25);
		background: var(--a-hover-bg);
		border-bottom-width: 3px;
		margin-bottom: -2px;
	}
	.toc a:not(:focus):not(:hover) {
		/* Allow colors to cascade through from link styling */
		border-bottom-color: transparent;
	}

	.toc, .toc ol, .toc ul, .toc li {
		list-style: none; /* Numbers must be inlined into source */
		/* because generated content isn't search/selectable and markers can't do multilevel yet */
		margin:  0;
		padding: 0;
	}
	.toc {
		line-height: 1.1em;
	}

	/* ToC not indented until third level, but font style & margins show hierarchy */
	.toc > li			{ font-weight: bold;   }
	.toc > li li		 { font-weight: normal; }
	.toc > li li li	  { font-size:   95%;	}
	.toc > li li li li	{ font-size:   90%;	}
	.toc > li li li li li { font-size:   85%;	}

	/* @supports not (display:grid) { */
		.toc > li			{ margin: 1.5rem 0;	}
		.toc > li li		 { margin: 0.3rem 0;	}
		.toc > li li li	  { margin-left: 2rem;   }

		/* Section numbers in a column of their own */
		.toc .secno {
			float: left;
			width: 4rem;
			white-space: nowrap;
		}
		.toc > li li li li .secno { font-size: 85%; }
		.toc > li li li li li .secno { font-size: 100%; }

		.toc li {
			clear: both;
		}

		:not(li) > .toc			 { margin-left:  5rem; }
		.toc .secno				 { margin-left: -5rem; }
		.toc > li li li .secno	  { margin-left: -7rem; }
		.toc > li li li li .secno	{ margin-left: -9rem; }
		.toc > li li li li li .secno { margin-left: -11rem; }

		/* Tighten up indentation in narrow ToCs */
		@media (max-width: 30em) {
			:not(li) > .toc			 { margin-left:  4rem; }
			.toc .secno				 { margin-left: -4rem; }
			.toc > li li li			 { margin-left:  1rem; }
			.toc > li li li .secno	  { margin-left: -5rem; }
			.toc > li li li li .secno	{ margin-left: -6rem; }
			.toc > li li li li li .secno { margin-left: -7rem; }
		}
		/* Loosen it on wide screens */
		@media screen and (min-width: 78em) {
			body:not(.toc-inline) :not(li) > .toc			 { margin-left:  4rem; }
			body:not(.toc-inline) .toc .secno				 { margin-left: -4rem; }
			body:not(.toc-inline) .toc > li li li			 { margin-left:  1rem; }
			body:not(.toc-inline) .toc > li li li .secno	  { margin-left: -5rem; }
			body:not(.toc-inline) .toc > li li li li .secno	{ margin-left: -6rem; }
			body:not(.toc-inline) .toc > li li li li li .secno { margin-left: -7rem; }
	}
	/* } */

	@supports (display:grid) and (display:contents) {
		/* Use #toc over .toc to override non-@supports rules. */
		#toc {
			display: grid;
			align-content: start;
			grid-template-columns: auto 1fr;
			grid-column-gap: 1rem;
			column-gap: 1rem;
			grid-row-gap: .6rem;
			row-gap: .6rem;
		}
		#toc h2 {
			grid-column: 1 / -1;
			margin-bottom: 0;
		}
		#toc ol,
		#toc li,
		#toc a {
			display: contents;
			/* Switch <a> to subgrid when supported */
		}
		#toc span {
			margin: 0;
		}
		#toc > .toc > li > a > span {
			/* The spans of the top-level list,
			  comprising the first items of each top-level section. */
			margin-top: 1.1rem;
		}
		#toc#toc .secno { /* Ugh, need more specificity to override base.css */
			grid-column: 1;
			width: auto;
			margin-left: 0;
		}
		#toc .content {
			grid-column: 2;
			width: auto;
			margin-right: 1rem;
		}
		#toc .content:hover,
		#toc .content:focus {
			background: rgba(75%, 75%, 75%, .25);
			background: var(--a-hover-bg);
			border-bottom: 3px solid #054572;
			border-bottom: 3px solid var(--toclink-underline);
			margin-bottom: -3px;
		}
		#toc li li li .content {
			margin-left: 1rem;
		}
		#toc li li li li .content {
			margin-left: 2rem;
		}
	}


/** Index *********************************************************************/

	/* Index Lists: Layout */
	ul.index	  { margin-left: 0; columns: 15em; text-indent: 1em hanging; }
	ul.index li	{ margin-left: 0; list-style: none; break-inside: avoid; }
	ul.index li li { margin-left: 1em; }
	ul.index dl	{ margin-top: 0; }
	ul.index dt	{ margin: .2em 0 .2em 20px;}
	ul.index dd	{ margin: .2em 0 .2em 40px;}
	/* Index Lists: Typography */
	ul.index ul,
	ul.index dl { font-size: smaller; }
	@media not print {
		ul.index li a + span {
			white-space: nowrap;
			color: transparent; }
		ul.index li a:hover + span,
		ul.index li a:focus + span {
			color: #707070;
			color: var(--indexinfo-text);
		}
	}

/** Index Tables *****************************************************/
	/* See also the data table styling section, which this effectively subclasses */

	table.index {
		font-size: small;
		border-collapse: collapse;
		border-spacing: 0;
		text-align: left;
		margin: 1em 0;
	}

	table.index td,
	table.index th {
		padding: 0.4em;
	}

	table.index tr:hover td:not([rowspan]),
	table.index tr:hover th:not([rowspan]) {
		color: black;
		color: var(--indextable-hover-text);
		background: #f7f8f9;
		background: var(--indextable-hover-bg);
	}

	/* The link in the first column in the property table (formerly a TD) */
	table.index th:first-child a {
		font-weight: bold;
	}

/** Outdated warning **********************************************************/

.outdated-spec {
	color: black;
	color: var(--outdatedspec-text);
	background-color: rgba(0,0,0,0.5);
	background-color: var(--outdatedspec-bg);
}

.outdated-warning {
	position: fixed;
	bottom: 50%;
	left: 0;
	right: 0;
	margin: 0 auto;
	width: 50%;
	background: maroon;
	background: var(--outdated-bg);
	color: white;
	color: var(--outdated-text);
	border-radius: 1em;
	box-shadow: 0 0 1em red;
	box-shadow: 0 0 1em var(--outdated-shadow);
	padding: 2em;
	text-align: center;
	z-index: 2;
}

.outdated-warning a {
	color: currentcolor;
	background: transparent;
}

.edited-rec-warning {
	background: darkorange;
	background: var(--editedrec-bg);
	box-shadow: 0 0 1em;
}

.outdated-warning button {
	color: var(--outdated-text);
	border-radius: 1em;
	box-shadow: 0 0 1em red;
	box-shadow: 0 0 1em var(--outdated-shadow);
	padding: 2em;
	text-align: center;
	z-index: 2;
}

.outdated-warning a {
	color: currentcolor;
	background: transparent;
}

.edited-rec-warning {
	background: darkorange;
	background: var(--editedrec-bg);
	box-shadow: 0 0 1em;
}

.outdated-warning button {
	position: absolute;
	top: 0;
	right:0;
	margin: 0;
	border: 0;
	padding: 0.25em 0.5em;
	background: transparent;
	color: white;
	color: var(--outdated-text);
	font:1em sans-serif;
	text-align:center;
}

.outdated-warning span {
	display: block;
}

.outdated-collapsed {
	bottom: 0;
	border-radius: 0;
	width: 100%;
	padding: 0;
}

/******************************************************************************/
/*                                    Print                                   */
/******************************************************************************/

	@media print {
		/* Pages have their own margins. */
		html {
			margin: 0;
		}
		/* Serif for print. */
		body {
			font-family: serif;
		}

		.outdated-warning {
			position: absolute;
			border-style: solid;
			border-color: red;
		}

		.outdated-warning input {
			display: none;
		}
	}
	@page {
		margin: 1.5cm 1.1cm;
	}



/******************************************************************************/
/*                             Overflow Control                               */
/******************************************************************************/

	.figure .caption, .sidefigure .caption, figcaption {
		/* in case figure is overlarge, limit caption to 50em */
		max-width: 50rem;
		margin-left: auto;
		margin-right: auto;
	}
	.overlarge {
		/* Magic to create good item positioning:
		  "content column" is 50ems wide at max; less on smaller screens.
		  Extra space (after ToC + content) is empty on the right.

		  1. When item < content column, centers item in column.
		  2. When content < item < available, left-aligns.
		  3. When item > available, fills available + scroll bar.
		*/
		display: grid;
		grid-template-columns: minmax(0, 50em);
	}
	.overlarge > table {
		/* limit preferred width of table */
		max-width: 50em;
		margin-left: auto;
		margin-right: auto;
	}

	@media (min-width: 55em) {
		.overlarge {
			margin-right: calc(13px + 26.5rem - 50vw);
			max-width: none;
		}
	}
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) .overlarge {
			/* 30.5em body padding 50em content area */
			margin-right: calc(40em - 50vw) !important;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) .overlarge {
			/* 4em html margin 30.5em body padding 50em content area */
			margin-right: calc(84.5em - 100vw) !important;
		}
	}

	@media not print {
		.overlarge {
			overflow-x: auto;
			/* See Lea Verou's explanation background-attachment:
			* http://lea.verou.me/2012/04/background-attachment-local/
			*
			background: top left  / 4em 100% linear-gradient(to right,  #ffffff, rgba(255, 255, 255, 0)) local,
						top right / 4em 100% linear-gradient(to left, #ffffff, rgba(255, 255, 255, 0)) local,
						top left  / 1em 100% linear-gradient(to right,  #c3c3c5, rgba(195, 195, 197, 0)) scroll,
						top right / 1em 100% linear-gradient(to left, #c3c3c5, rgba(195, 195, 197, 0)) scroll,
						white;
			background-repeat: no-repeat;
			*/
		}
	}
</style>
<style>
    table, th, td {
      border: 1px solid black;
      border-collapse: collapse;
      vertical-align: top;
    }
    th, td {
      border-left: none;
      border-right: none;
      padding: 0px 10px;
    }
    th {
      text-align: center;
    }

    del { background: #fcc; color: #000; text-decoration: line-through; }
    ins { background: #cfc; color: #000; }
    blockquote .highlight:not(.idl) { background: initial; margin: initial; padding: 0.5em }
    blockquote ul { background: inherit; }
    blockquote code.highlight:not(.idl) { padding: initial; }
    blockquote c-[a] { color: inherit; } /* Keyword.Declaration */
    blockquote c-[b] { color: inherit; } /* Keyword.Type */
    blockquote c-[c] { color: inherit; } /* Comment */
    blockquote c-[d] { color: inherit; } /* Comment.Multiline */
    blockquote c-[e] { color: inherit; } /* Name.Attribute */
    blockquote c-[f] { color: inherit; } /* Name.Tag */
    blockquote c-[g] { color: inherit; } /* Name.Variable */
    blockquote c-[k] { color: inherit; } /* Keyword */
    blockquote c-[l] { color: inherit; } /* Literal */
    blockquote c-[m] { color: inherit; } /* Literal.Number */
    blockquote c-[n] { color: inherit; } /* Name */
    blockquote c-[o] { color: inherit; } /* Operator */
    blockquote c-[p] { color: inherit; } /* Punctuation */
    blockquote c-[s] { color: inherit; } /* Literal.String */
    blockquote c-[t] { color: inherit; } /* Literal.String.Single */
    blockquote c-[u] { color: inherit; } /* Literal.String.Double */
    blockquote c-[cp] { color: inherit; } /* Comment.Preproc */
    blockquote c-[c1] { color: inherit; } /* Comment.Single */
    blockquote c-[cs] { color: inherit; } /* Comment.Special */
    blockquote c-[kc] { color: inherit; } /* Keyword.Constant */
    blockquote c-[kn] { color: inherit; } /* Keyword.Namespace */
    blockquote c-[kp] { color: inherit; } /* Keyword.Pseudo */
    blockquote c-[kr] { color: inherit; } /* Keyword.Reserved */
    blockquote c-[ld] { color: inherit; } /* Literal.Date */
    blockquote c-[nc] { color: inherit; } /* Name.Class */
    blockquote c-[no] { color: inherit; } /* Name.Constant */
    blockquote c-[nd] { color: inherit; } /* Name.Decorator */
    blockquote c-[ni] { color: inherit; } /* Name.Entity */
    blockquote c-[ne] { color: inherit; } /* Name.Exception */
    blockquote c-[nf] { color: inherit; } /* Name.Function */
    blockquote c-[nl] { color: inherit; } /* Name.Label */
    blockquote c-[nn] { color: inherit; } /* Name.Namespace */
    blockquote c-[py] { color: inherit; } /* Name.Property */
    blockquote c-[ow] { color: inherit; } /* Operator.Word */
    blockquote c-[mb] { color: inherit; } /* Literal.Number.Bin */
    blockquote c-[mf] { color: inherit; } /* Literal.Number.Float */
    blockquote c-[mh] { color: inherit; } /* Literal.Number.Hex */
    blockquote c-[mi] { color: inherit; } /* Literal.Number.Integer */
    blockquote c-[mo] { color: inherit; } /* Literal.Number.Oct */
    blockquote c-[sb] { color: inherit; } /* Literal.String.Backtick */
    blockquote c-[sc] { color: inherit; } /* Literal.String.Char */
    blockquote c-[sd] { color: inherit; } /* Literal.String.Doc */
    blockquote c-[se] { color: inherit; } /* Literal.String.Escape */
    blockquote c-[sh] { color: inherit; } /* Literal.String.Heredoc */
    blockquote c-[si] { color: inherit; } /* Literal.String.Interpol */
    blockquote c-[sx] { color: inherit; } /* Literal.String.Other */
    blockquote c-[sr] { color: inherit; } /* Literal.String.Regex */
    blockquote c-[ss] { color: inherit; } /* Literal.String.Symbol */
    blockquote c-[vc] { color: inherit; } /* Name.Variable.Class */
    blockquote c-[vg] { color: inherit; } /* Name.Variable.Global */
    blockquote c-[vi] { color: inherit; } /* Name.Variable.Instance */
    blockquote c-[il] { color: inherit; } /* Literal.Number.Integer.Long */
  </style>
  <meta content="Bikeshed version 1f1661843, updated Wed Dec 15 11:50:57 2021 -0800" name="generator">
  <link href="https://wg21.link/P2459" rel="canonical">
  <link href="https://isocpp.org/favicon.ico" rel="icon">
  <meta content="0d9e02960dea061cd0b8a14f19016aa056784087" name="document-revision">
<style>
table, th, tr, td {
  border: 2px solid black !important;
}
@media (prefers-color-scheme: dark) {
  table, th, tr, td {
    border: 2px solid white !important;
  }
}
</style>
<style>/* style-autolinks */

.css.css, .property.property, .descriptor.descriptor {
    color: var(--a-normal-text);
    font-size: inherit;
    font-family: inherit;
}
.css::before, .property::before, .descriptor::before {
    content: "‘";
}
.css::after, .property::after, .descriptor::after {
    content: "’";
}
.property, .descriptor {
    /* Don't wrap property and descriptor names */
    white-space: nowrap;
}
.type { /* CSS value <type> */
    font-style: italic;
}
pre .property::before, pre .property::after {
    content: "";
}
[data-link-type="property"]::before,
[data-link-type="propdesc"]::before,
[data-link-type="descriptor"]::before,
[data-link-type="value"]::before,
[data-link-type="function"]::before,
[data-link-type="at-rule"]::before,
[data-link-type="selector"]::before,
[data-link-type="maybe"]::before {
    content: "‘";
}
[data-link-type="property"]::after,
[data-link-type="propdesc"]::after,
[data-link-type="descriptor"]::after,
[data-link-type="value"]::after,
[data-link-type="function"]::after,
[data-link-type="at-rule"]::after,
[data-link-type="selector"]::after,
[data-link-type="maybe"]::after {
    content: "’";
}

[data-link-type].production::before,
[data-link-type].production::after,
.prod [data-link-type]::before,
.prod [data-link-type]::after {
    content: "";
}

[data-link-type=element],
[data-link-type=element-attr] {
    font-family: Menlo, Consolas, "DejaVu Sans Mono", monospace;
    font-size: .9em;
}
[data-link-type=element]::before { content: "<" }
[data-link-type=element]::after  { content: ">" }

[data-link-type=biblio] {
    white-space: pre;
}</style>
<style>/* style-colors */

/* Any --*-text not paired with a --*-bg is assumed to have a transparent bg */
:root {
    color-scheme: light dark;

    --text: black;
    --bg: white;

    --unofficial-watermark: url(https://www.w3.org/StyleSheets/TR/2016/logos/UD-watermark);

    --logo-bg: #1a5e9a;
    --logo-active-bg: #c00;
    --logo-text: white;

    --tocnav-normal-text: #707070;
    --tocnav-normal-bg: var(--bg);
    --tocnav-hover-text: var(--tocnav-normal-text);
    --tocnav-hover-bg: #f8f8f8;
    --tocnav-active-text: #c00;
    --tocnav-active-bg: var(--tocnav-normal-bg);

    --tocsidebar-text: var(--text);
    --tocsidebar-bg: #f7f8f9;
    --tocsidebar-shadow: rgba(0,0,0,.1);
    --tocsidebar-heading-text: hsla(203,20%,40%,.7);

    --toclink-text: var(--text);
    --toclink-underline: #3980b5;
    --toclink-visited-text: var(--toclink-text);
    --toclink-visited-underline: #054572;

    --heading-text: #005a9c;

    --hr-text: var(--text);

    --algo-border: #def;

    --del-text: red;
    --del-bg: transparent;
    --ins-text: #080;
    --ins-bg: transparent;

    --a-normal-text: #034575;
    --a-normal-underline: #bbb;
    --a-visited-text: var(--a-normal-text);
    --a-visited-underline: #707070;
    --a-hover-bg: rgba(75%, 75%, 75%, .25);
    --a-active-text: #c00;
    --a-active-underline: #c00;

    --blockquote-border: silver;
    --blockquote-bg: transparent;
    --blockquote-text: currentcolor;

    --issue-border: #e05252;
    --issue-bg: #fbe9e9;
    --issue-text: var(--text);
    --issueheading-text: #831616;

    --example-border: #e0cb52;
    --example-bg: #fcfaee;
    --example-text: var(--text);
    --exampleheading-text: #574b0f;

    --note-border: #52e052;
    --note-bg: #e9fbe9;
    --note-text: var(--text);
    --noteheading-text: hsl(120, 70%, 30%);
    --notesummary-underline: silver;

    --assertion-border: #aaa;
    --assertion-bg: #eee;
    --assertion-text: black;

    --advisement-border: orange;
    --advisement-bg: #fec;
    --advisement-text: var(--text);
    --advisementheading-text: #b35f00;

    --warning-border: red;
    --warning-bg: hsla(40,100%,50%,0.95);
    --warning-text: var(--text);

    --amendment-border: #330099;
    --amendment-bg: #F5F0FF;
    --amendment-text: var(--text);
    --amendmentheading-text: #220066;

    --def-border: #8ccbf2;
    --def-bg: #def;
    --def-text: var(--text);
    --defrow-border: #bbd7e9;

    --datacell-border: silver;

    --indexinfo-text: #707070;

    --indextable-hover-text: black;
    --indextable-hover-bg: #f7f8f9;

    --outdatedspec-bg: rgba(0, 0, 0, .5);
    --outdatedspec-text: black;
    --outdated-bg: maroon;
    --outdated-text: white;
    --outdated-shadow: red;

    --editedrec-bg: darkorange;
}</style>
<style>/* style-counters */

body {
    counter-reset: example figure issue;
}
.issue {
    counter-increment: issue;
}
.issue:not(.no-marker)::before {
    content: "Issue " counter(issue);
}

.example {
    counter-increment: example;
}
.example:not(.no-marker)::before {
    content: "Example " counter(example);
}
.invalid.example:not(.no-marker)::before,
.illegal.example:not(.no-marker)::before {
    content: "Invalid Example" counter(example);
}

figcaption {
    counter-increment: figure;
}
figcaption:not(.no-marker)::before {
    content: "Figure " counter(figure) " ";
}</style>
<style>/* style-issues */

a[href].issue-return {
    float: right;
    float: inline-end;
    color: var(--issueheading-text);
    font-weight: bold;
    text-decoration: none;
}
</style>
<style>/* style-md-lists */

/* This is a weird hack for me not yet following the commonmark spec
   regarding paragraph and lists. */
[data-md] > :first-child {
    margin-top: 0;
}
[data-md] > :last-child {
    margin-bottom: 0;
}</style>
<style>/* style-selflinks */

:root {
    --selflink-text: white;
    --selflink-bg: gray;
    --selflink-hover-text: black;
}
.heading, .issue, .note, .example, li, dt {
    position: relative;
}
a.self-link {
    position: absolute;
    top: 0;
    left: calc(-1 * (3.5rem - 26px));
    width: calc(3.5rem - 26px);
    height: 2em;
    text-align: center;
    border: none;
    transition: opacity .2s;
    opacity: .5;
}
a.self-link:hover {
    opacity: 1;
}
.heading > a.self-link {
    font-size: 83%;
}
li > a.self-link {
    left: calc(-1 * (3.5rem - 26px) - 2em);
}
dfn > a.self-link {
    top: auto;
    left: auto;
    opacity: 0;
    width: 1.5em;
    height: 1.5em;
    background: var(--selflink-bg);
    color: var(--selflink-text);
    font-style: normal;
    transition: opacity .2s, background-color .2s, color .2s;
}
dfn:hover > a.self-link {
    opacity: 1;
}
dfn > a.self-link:hover {
    color: var(--selflink-hover-text);
}

a.self-link::before            { content: "¶"; }
.heading > a.self-link::before { content: "§"; }
dfn > a.self-link::before      { content: "#"; }
</style>
<style>/* style-darkmode */

@media (prefers-color-scheme: dark) {
    :root {
        --text: #ddd;
        --bg: black;

        --unofficial-watermark: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='400' height='400'%3E%3Cg fill='%23100808' transform='translate(200 200) rotate(-45) translate(-200 -200)' stroke='%23100808' stroke-width='3'%3E%3Ctext x='50%25' y='220' style='font: bold 70px sans-serif; text-anchor: middle; letter-spacing: 6px;'%3EUNOFFICIAL%3C/text%3E%3Ctext x='50%25' y='305' style='font: bold 70px sans-serif; text-anchor: middle; letter-spacing: 6px;'%3EDRAFT%3C/text%3E%3C/g%3E%3C/svg%3E");

        --logo-bg: #1a5e9a;
        --logo-active-bg: #c00;
        --logo-text: white;

        --tocnav-normal-text: #999;
        --tocnav-normal-bg: var(--bg);
        --tocnav-hover-text: var(--tocnav-normal-text);
        --tocnav-hover-bg: #080808;
        --tocnav-active-text: #f44;
        --tocnav-active-bg: var(--tocnav-normal-bg);

        --tocsidebar-text: var(--text);
        --tocsidebar-bg: #080808;
        --tocsidebar-shadow: rgba(255,255,255,.1);
        --tocsidebar-heading-text: hsla(203,20%,40%,.7);

        --toclink-text: var(--text);
        --toclink-underline: #6af;
        --toclink-visited-text: var(--toclink-text);
        --toclink-visited-underline: #054572;

        --heading-text: #8af;

        --hr-text: var(--text);

        --algo-border: #456;

        --del-text: #f44;
        --del-bg: transparent;
        --ins-text: #4a4;
        --ins-bg: transparent;

        --a-normal-text: #6af;
        --a-normal-underline: #555;
        --a-visited-text: var(--a-normal-text);
        --a-visited-underline: var(--a-normal-underline);
        --a-hover-bg: rgba(25%, 25%, 25%, .2);
        --a-active-text: #f44;
        --a-active-underline: var(--a-active-text);

        --borderedblock-bg: rgba(255, 255, 255, .05);

        --blockquote-border: silver;
        --blockquote-bg: var(--borderedblock-bg);
        --blockquote-text: currentcolor;

        --issue-border: #e05252;
        --issue-bg: var(--borderedblock-bg);
        --issue-text: var(--text);
        --issueheading-text: hsl(0deg, 70%, 70%);

        --example-border: hsl(50deg, 90%, 60%);
        --example-bg: var(--borderedblock-bg);
        --example-text: var(--text);
        --exampleheading-text: hsl(50deg, 70%, 70%);

        --note-border: hsl(120deg, 100%, 35%);
        --note-bg: var(--borderedblock-bg);
        --note-text: var(--text);
        --noteheading-text: hsl(120, 70%, 70%);
        --notesummary-underline: silver;

        --assertion-border: #444;
        --assertion-bg: var(--borderedblock-bg);
        --assertion-text: var(--text);

        --advisement-border: orange;
        --advisement-bg: #222218;
        --advisement-text: var(--text);
        --advisementheading-text: #f84;

        --warning-border: red;
        --warning-bg: hsla(40,100%,20%,0.95);
        --warning-text: var(--text);

        --amendment-border: #330099;
        --amendment-bg: #080010;
        --amendment-text: var(--text);
        --amendmentheading-text: #cc00ff;

        --def-border: #8ccbf2;
        --def-bg: #080818;
        --def-text: var(--text);
        --defrow-border: #136;

        --datacell-border: silver;

        --indexinfo-text: #aaa;

        --indextable-hover-text: var(--text);
        --indextable-hover-bg: #181818;

        --outdatedspec-bg: rgba(255, 255, 255, .5);
        --outdatedspec-text: black;
        --outdated-bg: maroon;
        --outdated-text: white;
        --outdated-shadow: red;

        --editedrec-bg: darkorange;
    }
    /* In case a transparent-bg image doesn't expect to be on a dark bg,
       which is quite common in practice... */
    img { background: white; }
}
@media (prefers-color-scheme: dark) {
    :root {
        --selflink-text: black;
        --selflink-bg: silver;
        --selflink-hover-text: white;
    }
}

@media (prefers-color-scheme: dark) {
    .highlight:not(.idl) { background: rgba(255, 255, 255, .05); }

    c-[a] { color: #d33682 } /* Keyword.Declaration */
    c-[b] { color: #d33682 } /* Keyword.Type */
    c-[c] { color: #2aa198 } /* Comment */
    c-[d] { color: #2aa198 } /* Comment.Multiline */
    c-[e] { color: #268bd2 } /* Name.Attribute */
    c-[f] { color: #b58900 } /* Name.Tag */
    c-[g] { color: #cb4b16 } /* Name.Variable */
    c-[k] { color: #d33682 } /* Keyword */
    c-[l] { color: #657b83 } /* Literal */
    c-[m] { color: #657b83 } /* Literal.Number */
    c-[n] { color: #268bd2 } /* Name */
    c-[o] { color: #657b83 } /* Operator */
    c-[p] { color: #657b83 } /* Punctuation */
    c-[s] { color: #6c71c4 } /* Literal.String */
    c-[t] { color: #6c71c4 } /* Literal.String.Single */
    c-[u] { color: #6c71c4 } /* Literal.String.Double */
    c-[ch] { color: #2aa198 } /* Comment.Hashbang */
    c-[cp] { color: #2aa198 } /* Comment.Preproc */
    c-[cpf] { color: #2aa198 } /* Comment.PreprocFile */
    c-[c1] { color: #2aa198 } /* Comment.Single */
    c-[cs] { color: #2aa198 } /* Comment.Special */
    c-[kc] { color: #d33682 } /* Keyword.Constant */
    c-[kn] { color: #d33682 } /* Keyword.Namespace */
    c-[kp] { color: #d33682 } /* Keyword.Pseudo */
    c-[kr] { color: #d33682 } /* Keyword.Reserved */
    c-[ld] { color: #657b83 } /* Literal.Date */
    c-[nc] { color: #268bd2 } /* Name.Class */
    c-[no] { color: #268bd2 } /* Name.Constant */
    c-[nd] { color: #268bd2 } /* Name.Decorator */
    c-[ni] { color: #268bd2 } /* Name.Entity */
    c-[ne] { color: #268bd2 } /* Name.Exception */
    c-[nf] { color: #268bd2 } /* Name.Function */
    c-[nl] { color: #268bd2 } /* Name.Label */
    c-[nn] { color: #268bd2 } /* Name.Namespace */
    c-[py] { color: #268bd2 } /* Name.Property */
    c-[ow] { color: #657b83 } /* Operator.Word */
    c-[mb] { color: #657b83 } /* Literal.Number.Bin */
    c-[mf] { color: #657b83 } /* Literal.Number.Float */
    c-[mh] { color: #657b83 } /* Literal.Number.Hex */
    c-[mi] { color: #657b83 } /* Literal.Number.Integer */
    c-[mo] { color: #657b83 } /* Literal.Number.Oct */
    c-[sa] { color: #6c71c4 } /* Literal.String.Affix */
    c-[sb] { color: #6c71c4 } /* Literal.String.Backtick */
    c-[sc] { color: #6c71c4 } /* Literal.String.Char */
    c-[dl] { color: #6c71c4 } /* Literal.String.Delimiter */
    c-[sd] { color: #6c71c4 } /* Literal.String.Doc */
    c-[se] { color: #6c71c4 } /* Literal.String.Escape */
    c-[sh] { color: #6c71c4 } /* Literal.String.Heredoc */
    c-[si] { color: #6c71c4 } /* Literal.String.Interpol */
    c-[sx] { color: #6c71c4 } /* Literal.String.Other */
    c-[sr] { color: #6c71c4 } /* Literal.String.Regex */
    c-[ss] { color: #6c71c4 } /* Literal.String.Symbol */
    c-[fm] { color: #268bd2 } /* Name.Function.Magic */
    c-[vc] { color: #cb4b16 } /* Name.Variable.Class */
    c-[vg] { color: #cb4b16 } /* Name.Variable.Global */
    c-[vi] { color: #cb4b16 } /* Name.Variable.Instance */
    c-[vm] { color: #cb4b16 } /* Name.Variable.Magic */
    c-[il] { color: #657b83 } /* Literal.Number.Integer.Long */
}
</style>
 <body class="h-entry">
  <div class="head">
   <p data-fill-with="logo"></p>
   <h1 class="p-name no-ref" id="title">P2459R0<br>2022 January Library Evolution Poll Outcomes</h1>
   <h2 class="no-num no-toc no-ref heading settled" id="profile-and-date"><span class="content">Published Proposal, <time class="dt-updated" datetime="2022-02-15">2022-02-15</time></span></h2>
   <div data-fill-with="spec-metadata">
    <dl>
     <dt class="editor">Authors:
     <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:brycelelbach@gmail.com">Bryce Adelstein Lelbach (he/him/his) — Library Evolution Chair</a> (<span class="p-org org">NVIDIA</span>)
     <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:f.fracassi@gmx.net">Fabio Fracassi — Library Evolution Vice Chair</a> (<span class="p-org org">CODE University of Applied Sciences</span>)
     <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:ben.craig@gmail.com">Ben Craig — Library Evolution Vice Chair</a> (<span class="p-org org">NI</span>)
     <dt>Source:
     <dd><a href="https://github.com/brycelelbach/wg21_p2459_2022_january_library_evolution_poll_outcomes/blob/main/2022_january_library_evolution_poll_outcomes.bs">GitHub</a>
     <dt>Issue Tracking:
     <dd><a href="https://github.com/brycelelbach/wg21_p2459_2022_january_library_evolution_poll_outcomes/issues">GitHub</a>
     <dt>Project:
     <dd>ISO/IEC JTC1/SC22/WG21 14882: Programming Language — C++
     <dt>Audience:
     <dd>WG21
    </dl>
   </div>
   <div data-fill-with="warning"></div>
   <hr title="Separator for header">
  </div>
  <nav data-fill-with="table-of-contents" id="toc">
   <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
   <ol class="toc" role="directory">
    <li><a href="#introduction"><span class="secno">1</span> <span class="content">Introduction</span></a>
    <li><a href="#poll-outcomes"><span class="secno">2</span> <span class="content">Poll Outcomes</span></a>
    <li>
     <a href="#selected-poll-comments"><span class="secno">3</span> <span class="content">Selected Poll Comments</span></a>
     <ol class="toc">
      <li><a href="#poll-1"><span class="secno">3.1</span> <span class="content">Poll 1: <span>[P2300R4]</span> <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>execution</c-></code></span></a>
      <li><a href="#poll-2"><span class="secno">3.2</span> <span class="content">Poll 2: <span>[P2363R3]</span> Extending Associative Containers With The Remaining Heterogeneous Overloads</span></a>
      <li><a href="#poll-3"><span class="secno">3.3</span> <span class="content">Poll 3: <span>[P0493R3]</span> Atomic Maximum/Minimum</span></a>
      <li><a href="#poll-4"><span class="secno">3.4</span> <span class="content">Poll 4: <span>[P2286R6]</span> Formatting Ranges</span></a>
      <li><a href="#poll-5"><span class="secno">3.5</span> <span class="content">Poll 5: <span>[P2165R3]</span> Compatibility Between <code class="highlight"><c- n>tuple</c-></code>, <code class="highlight"><c- n>pair</c-></code>, And <code class="highlight"><c- n>tuple</c-></code>-Like Objects</span></a>
      <li><a href="#poll-6"><span class="secno">3.6</span> <span class="content">Poll 6: <span>[P2494R1]</span> Relaxing Range Adaptors To Allow For Move Only Types</span></a>
      <li><a href="#poll-7"><span class="secno">3.7</span> <span class="content">Poll 7: <span>[P2322R5]</span> <code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>fold</c-></code></span></a>
      <li><a href="#poll-8"><span class="secno">3.8</span> <span class="content">Poll 8: <span>[P2302R2]</span> <code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>contains</c-></code></span></a>
      <li><a href="#poll-9"><span class="secno">3.9</span> <span class="content">Poll 9: <span>[P1899R2]</span> <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>stride</c-></code></span></a>
      <li><a href="#poll-10"><span class="secno">3.10</span> <span class="content">Poll 10: <span>[P2474R1]</span> <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>repeat</c-></code></span></a>
      <li><a href="#poll-11"><span class="secno">3.11</span> <span class="content">Poll 11: <span>[P2508R1]</span> Expose <code class="highlight"><c- n>basic</c-><c- o>-</c-><c- n>format</c-><c- o>-</c-><c- n>string</c-><c- o>&lt;</c-><c- n>charT</c-><c- p>,</c-> <c- n>Args</c-><c- p>...</c-><c- o>></c-></code></span></a>
      <li><a href="#poll-12"><span class="secno">3.12</span> <span class="content">Poll 12: <span>[P2248R4]</span> Enabling List-Initialization For Algorithms</span></a>
      <li><a href="#poll-13"><span class="secno">3.13</span> <span class="content">Poll 13: <span>[P2404R2]</span> Move-Only Types For <code class="highlight"><c- n>equality_comparable_with</c-></code>, <code class="highlight"><c- n>totally_ordered_with</c-></code>, And <code class="highlight"><c- n>three_way_comparable_with</c-></code></span></a>
      <li><a href="#poll-14"><span class="secno">3.14</span> <span class="content">Poll 14: <span>[P2502R1]</span> <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>generator</c-></code></span></a>
     </ol>
    <li>
     <a href="#references"><span class="secno"></span> <span class="content">References</span></a>
     <ol class="toc">
      <li><a href="#informative"><span class="secno"></span> <span class="content">Informative References</span></a>
     </ol>
   </ol>
  </nav>
  <main>
   <h2 class="heading settled" data-level="1" id="introduction"><span class="secno">1. </span><span class="content">Introduction</span><a class="self-link" href="#introduction"></a></h2>
   <p>In January 2022, the C++ Library Evolution group conducted a series of
  electronic decision polls <a data-link-type="biblio" href="https://wg21.link/P2458R1">[P2458R1]</a>.
This paper provides the results of those polls and summarizes the results.</p>
   <p>In total, 65 people participated in the polls.
Some participants opted to not vote on some polls.
Thank you to everyone who participated, and to the proposal authors for all
  their hard work!</p>
   <h2 class="heading settled" data-level="2" id="poll-outcomes"><span class="secno">2. </span><span class="content">Poll Outcomes</span><a class="self-link" href="#poll-outcomes"></a></h2>
   <ul>
    <li data-md>
     <p>SF: Strongly Favor.</p>
    <li data-md>
     <p>WF: Weakly Favor.</p>
    <li data-md>
     <p>N: Neutral.</p>
    <li data-md>
     <p>WA: Weakly Against.</p>
    <li data-md>
     <p>SA: Strongly Against.</p>
   </ul>
   <table>
    <tbody>
     <tr>
      <th style="padding-bottom: 10px;">Poll 
      <th>SF 
      <th>WF 
      <th>N 
      <th>WA 
      <th>SA 
      <th>Outcome 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 1: Send <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> (<code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>execution</c-></code>) to Library Working Group for C++23, classified as a focus (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 1 item). 
      <td>23 
      <td>14 
      <td>0 
      <td>6 
      <td>11 
      <td>No consensus. There is sustained strong opposition against including such a large proposal into C++23 at such a late stage. It is also unclear whether we would be able to complete wording review in the limited time we have available. Timing is a major factor in the lack of consensus. The overall design still has strong support. The Chair, Bryce Adelstein Lelbach, asked Vice Chairs Fabio Fracassi and Ben Craig to determine consensus on this poll, as the Chair is one of the co-authors of P2300. The Chair fully supports their decision. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 2: Send <a data-link-type="biblio" href="https://wg21.link/p2363r3">[P2363R3]</a> (Extending Associative Containers With The Remaining Heterogeneous Overloads) to Library Working Group for C++23, classified as an addition (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 3 item). 
      <td>17 
      <td>17 
      <td>1 
      <td>1 
      <td>0 
      <td>Consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 3: Send <a data-link-type="biblio" href="https://wg21.link/p0493r3">[P0493R3]</a> (Atomic Maximum/Minimum) to Library Working Group for C++23, classified as an addition (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 3 item). 
      <td>17 
      <td>27 
      <td>2 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 4: Send <a data-link-type="biblio" href="https://wg21.link/p2286r6">[P2286R6]</a> (Formatting Ranges) to Library Working Group for C++23, classified as an addition (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 3 item). 
      <td>18 
      <td>17 
      <td>1 
      <td>1 
      <td>0 
      <td>Consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 5: Send <a data-link-type="biblio" href="https://wg21.link/p2165r3">[P2165R3]</a> (Compatibility Between <code class="highlight"><c- n>tuple</c-></code>, <code class="highlight"><c- n>pair</c-></code>, And <code class="highlight"><c- n>tuple</c-></code>-Like Objects) to Library Working Group for C++23, classified as an improvement of an existing feature (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 2 item). 
      <td>20 
      <td>14 
      <td>3 
      <td>2 
      <td>0 
      <td>Consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 6: Send <a data-link-type="biblio" href="https://wg21.link/p2494r1">[P2494R1]</a> (Relaxing Range Adaptors To Allow For Move Only Types) to Library Working Group for C++23, classified as an improvement of an existing feature (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 2 item). 
      <td>15 
      <td>15 
      <td>1 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 7: Send <a data-link-type="biblio" href="https://wg21.link/p2322r5">[P2322R5]</a> (<code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>fold</c-></code>) to Library Working Group for C++23, classified as an addition (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 3 item). 
      <td>16 
      <td>14 
      <td>2 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 8: Send <a data-link-type="biblio" href="https://wg21.link/p2302r2">[P2302R2]</a> (<code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>contains</c-></code>) to Library Working Group for C++23, classified as an addition (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 3 item). 
      <td>17 
      <td>16 
      <td>0 
      <td>0 
      <td>0 
      <td>Unanimous consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 9: Send <a data-link-type="biblio" href="https://wg21.link/p1899r2">[P1899R2]</a> (<code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>stride</c-></code>) to Library Working Group for C++23, classified as an addition (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 3 item). 
      <td>18 
      <td>13 
      <td>0 
      <td>0 
      <td>0 
      <td>Unanimous consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 10: Send <a data-link-type="biblio" href="https://wg21.link/p2474r1">[P2474R1]</a> (<code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>repeat</c-></code>) to Library Working Group for C++23, classified as an addition (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 3 item). 
      <td>22 
      <td>11 
      <td>1 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 11: Send <a data-link-type="biblio" href="https://wg21.link/p2508r1">[P2508R1]</a> (Expose <code class="highlight"><c- n>basic</c-><c- o>-</c-><c- n>format</c-><c- o>-</c-><c- n>string</c-><c- o>&lt;</c-><c- n>charT</c-><c- p>,</c-> <c- n>Args</c-><c- p>...</c-><c- o>></c-></code>) to Library Working Group for C++23, classified as an addition (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 3 item). 
      <td>19 
      <td>13 
      <td>2 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 12: Send <a data-link-type="biblio" href="https://wg21.link/p2248r4">[P2248R4]</a> (Enabling List-Initialization For Algorithms) to Library Working Group for C++23, classified as an improvement of an existing feature (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 2 item). 
      <td>6 
      <td>19 
      <td>6 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 13: Send <a data-link-type="biblio" href="https://wg21.link/p2404r2">[P2404R2]</a> (Move-Only Types For <code class="highlight"><c- n>equality_comparable_with</c-></code>, <code class="highlight"><c- n>totally_ordered_with</c-></code>, And <code class="highlight"><c- n>three_way_comparable_with</c-></code>) to Library Working Group for C++23, classified as an improvement of an existing feature (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 2 item). 
      <td>12 
      <td>10 
      <td>3 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 14: Send <a data-link-type="biblio" href="https://wg21.link/P2502R1">[P2502R1]</a> (<code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>generator</c-></code>) to Library Working Group for C++23, classified as a focus (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 1 item). 
      <td>18 
      <td>11 
      <td>1 
      <td>1 
      <td>1 
      <td>Consensus in favor. 
   </table>
   <h2 class="heading settled" data-level="3" id="selected-poll-comments"><span class="secno">3. </span><span class="content">Selected Poll Comments</span><a class="self-link" href="#selected-poll-comments"></a></h2>
   <h3 class="heading settled" data-level="3.1" id="poll-1"><span class="secno">3.1. </span><span class="content">Poll 1: <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>execution</c-></code></span><a class="self-link" href="#poll-1"></a></h3>
   <blockquote>
    <p>It’s finally real. This is the single most important thing we could deliver in C++23, so that we can deliver the next generation of facilities that depend upon it.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>We need this facility, and we need it soon. It’s still partial, and there’s more work to be done as extensions, but we need to get this work off the ground.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>We need this.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The perfect is the enemy of the good. This proposal is sufficiently baked and will have a huge impact on the C++ ecosystem. I don’t think C++ can afford to wait 3 more years for an asynchronous programming model.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>While I have some concerns about certain newer implementation details of the library, such as tag invoke, I have no concerns about the fundamental model that std::execution is based on. Continuations are a sound basis for computation, and it has been demonstrated that all basic control structures can be implemented with them, meaning that all terminating algorithms can be expressed as a graph of senders terminating in a receiver. The extra complication of having three channels is a consequence of the out of band nature of C++ exceptions and wanting to have a channel to provided cancellation.
The publicly available implementation and test suite also goes a long way to removing my implementation concerns.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p><a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> provides an essential foundation for structured concurrency in C++. This foundation can be used to add async sequences later.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p><a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> is a missing piece of C++ for most projects I’ve worked on. Accepting <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> would give us a standard way of writing code that can be executed on various execution contexts. The design space for this kind of functionality is vast. This fact obstructs composition of existing solutions and third-party code.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I believe that having a standardized model for concurrent and parallel execution is needed, and the sender receivers are the right model. This position is built on the experience with the framework used for the production code, which was independently iterated into using a model isomorphic to it.</p>
    <p>Furthermore, I am voting SF for this paper, with the full awareness that working on this paper consume all time available for the wording review, and prevent other paper from getting into it.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Here are some reasons why I favor this proposal.</p>
    <ul>
     <li data-md>
      <p>It results from collaboration between people who develop server-like, latency-bound concurrent code for more traditional CPUs, and people who develop bandwidth- and arithmetic-bound parallel code for GPUs.</p>
     <li data-md>
      <p>It’s been thoroughly reviewed by experts in many different areas of parallel and concurrent programming models.</p>
     <li data-md>
      <p>It provides a common low-level vocabulary for asynchrony and parallelism.</p>
     <li data-md>
      <p>It supports bulk execution. This is a key building block for asynchronous parallel algorithms. Without this, the proposal would be much less useful for many communities. C++20 does not expose asynchronous parallel algorithms at all, not even with custom execution policies. Thus, many communities are depending on bulk execution as a way to move away from nonstandard language extensions that can interact poorly with object lifetimes and standard execution ordering.</p>
     <li data-md>
      <p>The authors have shown themselves open to and interested in supporting a variety of use cases. They come to meetings with a listening attitude.</p>
     <li data-md>
      <p>The proposal gives programmers guidance for efficient synchronization. (The Networking TS gives programmers a bit too much freedom. Novices tend to respond to such freedom by reaching for more familiar but less efficient synchronization approaches.)</p>
     <li data-md>
      <p>The proposal has great examples. As a parallel computing expert, I really appreciate the parallel prefix scan example. As someone who occasionally has to deal with file I/O, I also appreciate the "asynchronous dynamically-sized read" example.</p>
    </ul>
    <p>Here are my remaining concerns with this proposal.</p>
    <ol>
     <li data-md>
      <p>It commits senders/receivers to use tag_invoke.</p>
     <li data-md>
      <p>It’s not clear yet whether <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> has a usable freestanding subset.</p>
    </ol>
    <p>Here is why I think these concerns should not block the proposal.</p>
    <ol>
     <li data-md>
      <p>Regarding tag_invoke: I agree with the authors that they need to solve the customization problem somehow. WG21 has not presented them with a language solution, so they chose the library solution that LEWG seems to favor the most. In recent years, WG21 seems to move more quickly on large libraries (e.g., ranges) than large language changes (e.g., contracts and reflection). Thus, I think <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a>'s authors made a pragmatic choice. That being said, tag_invoke will make stack traces harder to read, and will complicate customization.</p>
     <li data-md>
      <p>Per LEWG 2022/02/01 presentation of <a data-link-type="biblio" href="https://wg21.link/P2532R0">[P2532R0]</a>, dropping support for "untyped" senders will make it possible post R4 to remove most parts of <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> that require exception_ptr. The intent is to make a useful subset of <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> work without exception_ptr. I’m not a freestanding user or an embedded systems programmer, so I don’t think it’s appropriate for me to speak up on their behalf and address "concerns" I make up, that might not even exist. Freestanding experts and people who care about embedded systems have had long e-mail reflector discussions about <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> with its authors; while I’m not an expert, the discussions sounded generally positive, and the authors addressed the reasonable concerns.</p>
    </ol>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This proposal goes in depth with all details, provides a valid model, and is based on a library with a fair amount of experience.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is ready. It’s been through so many iterations.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>S&amp;R is developed as a unifying async model for Standard C++ that can suit parallelism &amp; GPU compute. It is the analogue of what STL algorithms/iterators did for serial compute for async compute.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a great, flexible design for concurrent processing.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is an important set of foundational pieces for async for C++23. Some of it could be temporarily removed if it introduces review complications - bulk for example could still be a concern for people without good examples of how to build larger algorithms using it. The most important thing is that the core concepts go in, and the ability to pass information through receivers, because all of this aligns us with a good foundation like we have for coroutines.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The industry badly needs to move toward structured concurrency. This is a strong first step.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>it’s essential that we have a strong, structured model for building concurrency in C++</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This feature will be a big and long overdue improvement for C++ programmers trying to use modern algorithmic paradigms and patterns.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is good. This is needed. Ship it!</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>We need an executors library, and <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a>] is what we need.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Parallelism and asynchrony have been around for decades, and yet it is still "novel" in the C++ language. Senders/receivers is a baked, generic model for asynchronous work. Waiting for a future C++ standard would set the community back even further.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The C++ library desperately needs some mechanism for managing the execution of asynchronous work. The current paper is the culmination of a long and wide-ranging design process, and it provides a reasonably well-founded solution to that problem.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The paper is in a good enough shape for C++23. The opportunity cost of delaying structured concurrency until C++26 is too high.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>While I am not sure how far this proposal will carry us in terms of providing meaningful generic interfaces to express parallelism for all kinds of hardware architectures, it is in my opinion good enough to move us forward. And this has been forever in discussion and I don’t see how adding another 3 years of design work will get us to something better.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I have been watching <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> and its predecessors for a long time, and believe it’s an important advance for async in C++.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>The main design is ready, but I think it could use some hardening, and it <em>really</em> needs streams. I’d like to see affirmatives over "we were able to implement networking" and "we were able to implement audio" on top of <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> to really be sure it belongs into the working draft for 23.</p>
    <p>I would not be sad if this got merged into the WD for 26 and improved on with subsequent papers. 23 seems like rushing it, a bit.</p>
    <p>Nevertheless, I think the design is sufficiently vetted to make 23, if LWG can make time to sign off on it.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I am eager to get <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> but I also think it is still somewhat in flux. For example, I’m still not confident that the cancellation interface is complete.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I am far from an expert here, but support the overall design and approach.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>R3 and R4 have addressed many of my concerns. It remains unclear whether transitions between schedulers can be made portable, but the interface and design have converged on something otherwise solid.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I would love to have an alternative channel in the execution proposal which pass errors as return values, I hope authors could explore this direction.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>While I have some concerns about the ergonomics of tag_invoke (compared to a language solution; as a library solution it’s great), the general concepts and algorithms for asynchrony in <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> are sound and important for the future of C++.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is an important building block and foundation for C++'s async programming model. While the timeline is tense, I think we should stabilize the model now, if we can.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Having some executor (or executor-like) feature in the standard has been a goal for several cycles. Having finally achieved consensus for a low-level feature, progress on the higher-level components like Networking can resume for the next cycle without worrying that they will be deferred for extrinsic reasons yet again. The late-breaking changes are a concern but do not seem to rise to the level of a reason to abort.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>tag_invoke is a bit clunky, but it works well enough and it would be good to get std::execution into the standard for implementors to have something firm to work from.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I am still a little reluctant about advancing this paper. I feel that although the paper has enjoyed plenty of review, I
haven’t seen enough implementation experience from people outside of the authorship group. Something as critical as this needs a lot of shaking down, more than we’ve seen so far.</p>
    <p>However, there comes a point where we have to let the specification group give their input, so I weakly favour forwarding this paper to LWG.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>It’s a very complicated beast that will be fun to play with and teach once it has settled and been made available. Some of the examples in the paper seem (to me) to obscure the relevant aspects of the proposal, but others work well in my eyes (in particular, Dietmar’s echo server is interesting in that it seems to approach the relative simplicity of an echo server in Erlang where writing such a process is easy). I cannot take a stronger stance without playing wth it first due to the size and complexity of the proposal.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I do not feel that I have sufficient information to meaningfully vote here.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>I’m abstaining because I haven’t tracked <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> for a long time. For historical perspective, I am very in favour of <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> for C++, but was strongly against its integration into C++23 when I was tracking it in 2021, as I felt it didn’t have enough bake time, and don’t want to have a repeat of what happened with ranges in C++20. I’d probably vote SF on the first C++26 poll (assuming I started following it again).</p>
    <p>TL;DR I’m concerned about bake time, but feel I don’t have a right to vote.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>I don’t have any objection to <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> as the basis for executors, but I don’t see anything that motivates it’s inclusion in C++23 either, .e.g. "What’s it good for?" - certainly no guidance as to how one might do Networking (or other kind’s of reactive IO) with <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> nor does <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> say anything about how one might use it for parallel algorithms.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>There is about a 100 pages of wording and quite a lot of changes between the latest revisions of the <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> proposal. It jeopardizes the overall C++23 schedule. Moreover, there is no ASIO implementation using the <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> approach and most of the known to me users wish to use executors only for Networking. Without type erased facilities the proposal does not provide a useful vocabulary type for interaction of different libraries and projects, so there’s no urge to have the feature in C++23.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>I like the direction for std::execution, and I think that sender-receiver is a good model for parallel and asynchronous execution. However, I do not think that this is ready for C++23. I would like to see <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> added to the working draft early in the C++26 cycle, which will give us the opportunity to gain some implementation experience (including multiple implementations from the specification) and to add in <em>necessary</em> complementary features, such as integration with PSTL, a system thread pool, etc. I believe that having another cycle’s worth of maturity and experience would be the best outcome for std::execution, bearing mind that this is an enormous proposal that is less than 6 months old.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>The discussions have made it clear that this proposal is not sufficiently stable to include in C++23.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>I don’t feel this is mature enough to rush into C++23. I don’t see it actually solving the problems that we’ve been looking for executors to solve (networking, PSTL backend etc.)
Interesting and worth pursuing, but not ready for C++23</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>There are recent changes. These are problems that may or may not be fundamental but indicate immaturity and use only in limited domains: and the proposal supports a narrower set of use cases than the networking TR ones, that the case that is supports the low-latency applications for which the networking TR is frequently used with the necessary responsiveness is unproven, that the allocation strategy is limiting and can be sub-optional, that cancellation is messy, that error-handling seems immature. This detracts from the virtues that the proposal has and indicates that further work is needed before standardization. This work cannot be completed in time for C++23.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <blockquote>
    <p>There are many aspects of <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> (and senders and receivers more generally) that excite and interest me, particularly the way operation states allow the ecosystem to leverage C++17 guaranteed copy elision and allow asynchronous code to be written without allocation. I support continued discussion and consideration of the paper, and would vote SF to advance some future version of the paper.</p>
    <p>However given how late-breaking this paper was, given how much prior work it overturned, and given the fact that there are concerns with the chosen design (which I share) I don’t feel comfortable voting it forward at this time. Particularly:</p>
    <p>The chosen design does not seem to have an intrinsic, generic mechanism for breaking the call stack and solving the kinds of reentrancy problems one gets into when authoring certain classes of asynchronous algorithm. The chosen design is a powerful and expressive solution for computations which are modeled as DAGs but there are classes of asynchronous algorithms (particularly in I/O) which cannot be modeled as a DAG because they contain cycles. As it stands the proposed design does not seem to have a generic solution to this: You can choose a particular scheduler with a particular implementation and use it in a particular way to avoid the possibility of stack overflows but you cannot do it generically the way you could with, for example, blocking.never from <a data-link-type="biblio" href="https://wg21.link/p0443r14">[P0443R14]</a>.</p>
    <p>The chosen design exposes authors of asynchronous algorithms to errors which occur not just in the execution of their child algorithms as such, but also errors which occur scheduling the pieces of those algorithms. This is morally good however the fact that all this error information flows through set_error and is not otherwise differentiated raises questions about how one should implement algorithms which wish to retry on certain classes of error but not others in a generic fashion. Also in making an invocation of set_error mandatory it weakens the ability to reason about which contexts can invoke set_error and which cannot (i.e. it can increase the cognitive overhead of writing correct code in the face of parallelism).</p>
    <p>The "receiver contract" requires that set_error, set_value, or set_done be called successfully for each connected receiver, even if the associated machinery is in the process of being destroyed. This creates ambiguity for algorithms which wish to handle cancellation or error by continuing: How do they differentiate the set_error and/or set_done indicating that the world is ending from the set_error and/or set_done which arises during normal operation? What’s the generic solution for avoiding chains of work infinitely extending themselves during shutdown? In prior art where shutdown was communicated via the destructor firing it was understood through well-established convention that this means that the ability to run work was ending and that it should not be extended.</p>
    <p>It’s possible that all my concerns can be addressed within the current <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> framework and/or that they can be handled solely additively through future papers or versions of the standard. However given the stakes and the fact that this is a library-only feature (if people are eager to get their hands on it they can download a third party implementation thereof) I don’t feel comfortable voting this forward at the present time.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <blockquote>
    <p>From the high level perspective: on one hand, the paper looks too big to include just the basics, on the other hand, it doesn’t look sufficient by itself because there is a huge amount of work to do in a combination with <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a>. For example: we don’t have parallel algorithms (Parallel STL) defined in terms of schedulers/senders/receivers, we don’t have (potentially replaceable) standard execution context that is good enough for the parallel algorithms and that composes well with the rest of the library, we don’t some abstraction to unite the "group of tasks" and wait on all of them, we don’t have type_erased sender, etc. I know that people work in those directions (including myself) but I feel like we don’t get enough experience with paradigms in <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> and thus, don’t have enough confidence that everything works all together without any issues.</p>
    <p>I still have open questions about the design:</p>
    <ul>
     <li data-md>
      <p>The proposal chooses lazy execution as the basis and that’s probably fine but we need to make sure that we can build eager execution on top of that. Authors claim it is possible and I believe in that but the devil is in the details.</p>
     <li data-md>
      <p>There is no way to get know if nested parallelism is supported by Execution Context or not. By nested parallelism I mean some algorithm that is blocking within another algorithm (for example: we call bulk within bulk and for nested bulk we wait for completion within top level bulk). For some execution contexts such scenario is supported well (e.g. TBB), for others it’s not (e.g. SYCL), there is a third set for which it’s possible but the efficiency depends on the implementation (e.g. OpenMP). Seems like we need a property at least to query that. There are other close questions with that regard but those seem like too detailed to be mentioned here.</p>
     <li data-md>
      <p>I wrote this point above but want to duplicate that. From our experience type-erased sender (and probably type-erased scheduler) is essential.</p>
     <li data-md>
      <p>Generic concern: To me design is changing quite often on the fly that also makes me think that field experience is not sufficient.</p>
    </ul>
    <p>Giving all what I’ve said above I think we should have more experience with increasing the confidence, address design questions and make the design stable before shipping <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a>, ideally, with having the complete solution (not just <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a>) or at least have enough understanding and answers that the bigger picture works without problems, composes well and gives reasonably good performance.</p>
    <p>Independently of my vote, I am ready to continue the collaboration and continue contributing and improving the solution for basic asynchrony model and structured concurrency for C++.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <blockquote>
    <p>Have we learned nothing from the unprecedented number of library papers that had to be DRs against C++20?</p>
    <p>The design has been changing up to the very end. The paper does not even report a complete reference implementation, much less usage experience, of the facilities as actually specified in the paper. The features we’ve had to patch up in C++20 had far more implementation and usage experience than <em>that</em>.</p>
    <p>I still think the general direction is sound, but rushing this into C++23 makes no sense to me. Having spent a ton of my time in the C++23 cycle patching up ranges, I have no interest whatsoever in repeating that experience.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <blockquote>
    <p>This has seen way too few field experience in a lot of target domains to give any confidence that the design has really settled. If we standardize this now, some fundamental design flaws will surface only after it’s too late to change this version, with the result that we have to ship a slightly different version under a slightly different name later.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <blockquote>
    <p>This paper is making design decisions - and not ones motivated by LWG feedback - after the vote to forward it was taken. It is not ready and we should not rush it. Nothing will collapse if this does not make C++23.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <blockquote>
    <p><a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> is a complex proposal and there are too many open questions related to the proposal. I think it would be a mistake to commit to this direction until those questions are answered. In particular, I am concerned that the proposal will not effectively work with eager execution. While we might be able to shoe-horn in eager execution using the P5 features including ensure_started and async_scope, the proposal is biased towards a purely lazy execution model. The first version of <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a>, only a few months ago, included possibly eager variants of all of the algorithms. I am simply not yet convinced that the “long-standing belief that eager execution is a mandatory feature” (Section 4.11), and the possibly-eager versions of the algorithms, should be so easily dismissed. I believe more work is needed to be sure that nothing in the proposal precludes common use cases expected by users – i.e. invoke an async algorithm that starts eagerly (at the discretion of the implementation) but also can be chained to other related work. I acknowledge the complications described in Section 4.11, but think it is a mistake to put off a decision and assume that a future solution will be fully compatible with what is proposed in <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> today. Also, because of the rapidly moving target that <a data-link-type="biblio" href="https://wg21.link/p0443r14">[P0443R14]</a> and the <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> has been over the last two years, it has been impossible to fully evaluate the usability of senders/receivers with our existing runtimes, performance libraries and programming models. In the fall, we spoke with the authors and expressed our concerns around eager execution, bulk execution, low-level tasking on the CPU, and the lack of a complete picture of how asynchronous versions of the STL algorithms will be designed in a way that they can be practically customized. While discussions were started, we asked for companion papers related to these topics that fleshed out those details. There was simply, and understandably, not time to complete (or even) start those papers in the meantime. While it may turn out that <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> is sufficient for our use cases and customers, we are not convinced of that and, in fact believe it is likely not the case, so would prefer to be more certain before committing to standardization of a feature that may not be sufficient for our customers' needs.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <blockquote>
    <p>This is the right design, and represents decades of work and refinement by many people, and I’m happy to see it take shape. It is, however, not baked.</p>
    <p>Here are our choices</p>
    <ul>
     <li data-md>
      <p>Forward <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> now to LWG, and force them to spend the next few months doing mainly that, at the cost of everything else, with no guarantee that this gets into the standard, at this point WG21 will have little to show for its effort.</p>
     <li data-md>
      <p>Or, we can keep working in lewg AND ewg over the next few months maturing the paper, and gaining the confidence that no corner is cut for the sake of self-imposed deadline.</p>
    </ul>
    <p>As it stands, we would be shipping</p>
    <ul>
     <li data-md>
      <p>An execution proposal without a place to execute anything, as <a data-link-type="biblio" href="https://wg21.link/p2079r2">[P2079R2]</a> has not progressed. As such this proposal is not usable by the community. Yes, I know. run_loop. run_loop is very cute,</p>
     <li data-md>
      <p>An execution proposal that doesn’t support any kind of I/O, not even timers.</p>
     <li data-md>
      <p>A proposal that is mostly based on tag_invoke CPO, despite the shortcomings of tag_invoke, and the documented need for a language solution. We know that Lewis is working on exactly that, and we should not let Conway’s law get in the way of good design. There is agreement that tag_invoke isn’t great (but it helped define what a language solution needs, and in that it was very useful, it is also amazingly clever). Let’s fix that. Let’s not pretend EWG is some mystical  secret cabal we have no influence over, Let’s meet on a Wednesday instead of a Monday. I do not believe that tag_invoke will be used correctly (i.e. in a way that isn’t detrimental to compile time performance and or otherwise incorrect by most users). I also firmly believe that once tag_invoke ships, there would be negative value in exploring language solutions, we already have too many different approaches to CPOs, and it would be a shame that our enthusiasm for <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> would close the door to that design space forever, forcing our users to contend with ADL and other arcane lookup rules forever.</p>
     <li data-md>
      <p>A proposal that we voted to make important changes AFTER it was sent to electronic polling. Freestanding is important and we should find a good solution to this use case. We did extensive surgery at the last 2 meetings, and the authors did an amazing job turning around very quickly, but that doesn’t inspire confidence that more surgery isn’t needed (getting rid of untyped senders is a good thing).</p>
    </ul>
    <p>This is the bad side effects of <a data-link-type="biblio" href="https://wg21.link/p1000r4">[P1000R4]</a>, <a data-link-type="biblio" href="https://wg21.link/p2000r3">[P2000R3]</a> and <a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a>. By keeping hammering that a specific area is of higher priority and should be treated with swiftness, we end up compromising on design. We have blocked much smaller papers over much better wording. We should have a level of care that is proportional to the size and importance of the paper rather than inversionally proportional. And yes, we all understand that <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> is VERY important and this is why rushing is exactly the thing we should not do.</p>
    <p>I do not blame the authors here, it took many meetings convincing LEWG that this was the right architecture, we were left with time to look at the minutiae of the design. Probably not lost time though, <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> is in a great place compared to <a data-link-type="biblio" href="https://wg21.link/p0443r14">[P0443R14]</a>. But we did the mistake of not refining coroutines in 20 (instead spending times comparing them to theoretical models), and I have regretted to vote to forward them (my logic at the time was that shipping something good, albeit imperfect, was better overall for the community), a decision which I have regretted. I can’t do that again. <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> is too fundamental to the shape of the STL in the next decades to rush.</p>
    <p>There are things that we could do, and probably won’t:</p>
    <ul>
     <li data-md>
      <p>Use the few months left before the DIS to focus on <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> in both EWG, EWG and joint sessions and replace tag_invoke. This would require heroics.</p>
     <li data-md>
      <p>Delay C++23 by 4 to 8 months, on the account that there is a pandemic, and instruct EWG to come up with language CPO during that time. It could still be called c++23, although we probably won’t have time to translate the standard in french...</p>
     <li data-md>
      <p>Delay <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> to 26, but vow to keep working on it, in both groups in the next few months, and merge it in the working draft early.</p>
    </ul>
    <p>— Strongly Against</p>
   </blockquote>
   <blockquote>
    <p>I think at this point it would be better to proceed with <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> as (a part of) a technical specification rather than including it into the standard. For the latter, <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> is not sufficiently complete/elaborated to cover all areas of concern, yet it goes well beyond the basic mechanics for supporting concurrency and asynchrony. The proposal is non-obvious and requires deep understanding of novel concepts, which does not seem built in the community yet. The amount and depth of changes in every new update to the paper reduces confidence in maturity of <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a>. All in all, it looks more like a work-in-progress on a useful functionality rather than a well-baked standardization proposal.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <blockquote>
    <p>I do not think that the <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> paper is ready for C++23. It has gone through a lot of late design changes and the dust hasn’t really settled on it, IMO.</p>
    <p>There are still some questions and concerns regarding the approach for <code class="highlight"><c- n>bulk</c-></code> - I don’t think we have the right design for expressing forward progress/concurrency constraints there yet. I think the guidance given to not have a default implementation of <code class="highlight"><c- n>bulk</c-></code> is a poor direction and is user-hostile for generic algorithms.</p>
    <p>We really need to have the async_scope functionality included to allow this to replace the <code class="highlight"><c- n>ensure_started</c-></code> and <code class="highlight"><c- n>split</c-></code> algorithms. I have concerns about safety of <code class="highlight"><c- n>ensure_started</c-></code> and the semantics of <code class="highlight"><c- n>split</c-></code> under cancellation is surprising.</p>
    <p>For a lot of the functionality to be useful out of the box we should ideally ship a system executor/thread-pool.</p>
    <p>We have not yet demonstrated that the parallel algorithms are efficiently/conveniently implementable on top of the basis functions in this proposal. I would like to see implementation experience here before shipping <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a>.</p>
    <p>I also think that <code class="highlight"><c- n>tag_invoke</c-></code> is not the right direction for the Standard Library to take for customisable functions and that a language solution should be used here - shipping <code class="highlight"><c- n>tag_invoke</c-></code> will basically commit us to using that as the solution ongoing due to ecosystem effects of facilities that will be built on top of <code class="highlight"><c- n>tag_invoke</c-></code>, even if we ship a language solution in future. A paper proposing such a language solution is forthcoming and will be targeting C++26.</p>
    <p>I think that the remaining LWG time for C++23 would be better spent on finalising the other proposals already in their queue rather than on trying to ship std::execution which is a large amount of wording to review and might not make it anyway.</p>
    <p>I would rather try to target <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> to be merged early in the C++26 cycle to give time for recent design changes to stabilise and to give the language customisation points feature a chance to land so that <a data-link-type="biblio" href="https://wg21.link/p2300r4">[P2300R4]</a> can be built on that instead of tag_invoke.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <blockquote>
    <p>It is too late in the C++23 cycle to put something that is so novel and in so much flux. If I were an implementer, I would be extremely hesitant to implement this in a non-experimental way for a few years, as I would be afraid of compatibility and ABI breaks early in the C++26 cycle, much as we had with std::format and ranges.</p>
    <p>I would be neutral for the paper as is sent to C++26. There are papers on the way that are likely to sway me to weakly in favor for C++26.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.2" id="poll-2"><span class="secno">3.2. </span><span class="content">Poll 2: <a data-link-type="biblio" href="https://wg21.link/p2363r3">[P2363R3]</a> Extending Associative Containers With The Remaining Heterogeneous Overloads</span><a class="self-link" href="#poll-2"></a></h3>
   <blockquote>
    <p>This is a quality-of-life fix in an important facility. It makes C++ more uniform.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Makes things more consistent.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Many supportive feedback. Known issues were addressed, design decisions and considerations are reflected in the paper.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Covers a niche use-case, but this will make associative containers a bit better.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This fixes interface irregularities (why is find heterogeneous but at/op[] isn’t?) and makes the class design more consistent.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This helpful generalization immediately improves the usability of standard containers.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I am the author of this proposal; my motivation is already discussed in the proposal.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This should honestly be a DR back to the beginning of time but I know people aren’t as aggressive as I am in wanting good things back in the old days. So this is fine.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is janitorial. Very welcome.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Even though I have not participated in previous discussions about the paper, I was able to understand it and evaluate various tradeoffs the authors have made. The addition is obviously of value, and the tradeoffs are meaningful for me.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Without the heterogeneous overloads for functions on associative containers it was impossible to write code against associative containers of std::string without paying for what you don’t use. Especially since std::string_view is part of the library we should push forward adding these overloads wherever possible.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>While I have not participated in the discussion around this topic in LEWG, I have spoken several times with the authors about this proposal and believe it to be a common-sense extension that is in-line with previous extensions around heterogeneous overloads.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Improves library consistency / meets expectations.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This paper slightly complicates operator[]; I hope users don’t get mad about it.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This closes an important gap.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The feature was requested multiple times by users from different domains.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Helps with completeness.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This proposal helps prevent superfluous allocation of temporary values for more cases. It also makes behavior more consistently good across more functions. I also appreciate that the authors include benchmark results. I would expect to see some benefit from this change in the projects I work on.</p>
    <p>The authors carefully discuss the issue that the new overloads would make it possible to insert, etc. keys that are only explicitly convertible to key_type. This is already an issue with the Standard Library, where some functions open a loophole around the type itself not permitting implicit conversion. For most code where this matters to me, I know the key type of the container where I’m calling "insert" etc. It’s also easier to notice insert-related conversions, than it is to notice general conversions in generic code. Thus, I’m not so worried about this.</p>
    <p>The paper gives examples showing how inconsistency between conversion and heterogenous comparison can get users into trouble, even without the proposed changes. I agree; making those two things inconsistent feels just as much of a trap as making + and += have different mathematical meaning. It feels like there is some missing concept in the Standard Library, analogous to "regular," for "type U’s conversions and heterogeneous comparisons are consistent with type V’s."  I don’t think the paper necessarily needs that, as most of the concept’s value would be semantic, but it might help with wording or teaching.</p>
    <p>The only reason I’m not voting SF, is because I’m not enough of an expert on the potential ambiguities that this proposal might introduce.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Unfortunately this feature has some sharpish edges, but the efficiency improvement probably justifies it.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Arguably bucket 3, as this is a performance bug fix. We keep adding stringy things, so being able to deal with heterogeneous key comparisons is important.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Seems consistent and fine.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>A straightforward improvement to the associative container API that makes it more consistent and efficient.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This will extend the usability of the library.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I would hope that the containers move to a CPO based model for methods that apply to more than one container. adding methods piecemeal is fraught with chances for inconsistencies.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Increases both code performance and language completeness. The status quo of having only a subset of container member functions support heterogeneous lookup is surprising and also hampers teachability.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>The arguments for it seem compelling.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This completes other work we’ve done on heterogeneous overloads. It’s always nice to be consistent.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Providing the additional heterogeneous operations on map, et.al., after providing for lookup, seems like a worthwhile extension.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’m torn on whether this does more good than harm. The benefits are convincing, but the new "explicit" bypassing is also a bit concerning. I will trust the wider committee opinion.</p>
   </blockquote>
   <blockquote>
    <p>The title sounds good, but I haven’t read the paper.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>The additional restriction that the lookup type be convertible to the key type somewhat reduces the importance of these overloads, but they’re surely useful nonetheless. I haven’t paid attention to see if there are any unfortunate interactions with them.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>I am not convinced by the explanation of the behavior of the functions that modify or erase elements from the container are intuitive when they are multiple matches. As an illustration for such type, we could consider map that uses ratio as a key (not reduced, where 1/2 is different than 2/4), that is looked up using always reduced fraction. The fraction can still be converted to a ratio.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.3" id="poll-3"><span class="secno">3.3. </span><span class="content">Poll 3: <a data-link-type="biblio" href="https://wg21.link/p0493r3">[P0493R3]</a> Atomic Maximum/Minimum</span><a class="self-link" href="#poll-3"></a></h3>
   <blockquote>
    <p>This is a very useful feature and would eliminate a lot of uses of the manual CAS loop from the standard, even if case when a more performant implementation is possible. Change to provide more portable behavior is a good direction.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The paper has explored all design issues extensively and managed to resolve all of them. It’s the correct design, and a useful one. We should have it in the standard.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>A useful addition.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>An important facility, and important to do in the library rather than let users attempt themselves.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Atomic min/max are useful operations. They also extend the existing set of atomic reduction operations. Many programming environments, such as OpenMP, expose atomic min/max. Coders who wanted these operations generally had to reach for hardware-specific instructions, and provide a CAS loop for types that the hardware does not support. This feature makes such hardware- and platform-specific code unnecessary.</p>
    <p>Section 5 talks about the "interesting" part of this proposal. The atomic min/max provided by some APIs and hardware have the effect of a read-modify-write, whether or not the value actually changes. On other hardware, atomic min/max has the effect of a read-and-conditional-store. LEWG was not keen on letting this behavior be unspecified. SG1’s advice was that the method could be implemented in a way that requiring an unconditional write in a CAS-loop algorithm did not have much overhead. Therefore, requiring read-modify-write behavior was acceptable.</p>
    <p>I’m a bit sad about this limit on implementation freedom. On the other hand, read-modify-write is how atomic min/max behave on most hardware and in many common programming models. It’s also consistent with the existing atomic operations (e.g., fetch_add) in the C++ Standard Library. I appreciate the authors' benchmarking effort, and the extra advice from SG1.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The lack of this has bitten me on more than one occasion, well worth it.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Atomic Max and Min are very useful operations that have wide hardware support via CAS loops, yet currently programers must workaround the lack of support. This is particularly an issue on hardware platforms that native hardware atomic operations for these, since portable C++ programs using workarounds typically won’t leverage this there.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is an important operation for many algorithms.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>We had to implement the conditional write optimization in RAJA, Kokkos and DESUL and it would be great to not have to do that anywhere else.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This extends the C++ memory model to support and abstract an operation that we are increasingly seeing supported directly by hardware. Performance is acceptable enough for the platforms where this falls back to CAS loops. Plus, if you need to do this and we don’t provide it, you’ll probably end up writing something worse yourself.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’ve reached for these functions many times only to be disappointed to find that they don’t exist.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a valuable enhancement which follows practice in the field</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Min and Max atomics are actually fairly important atomic operations we use regularly. Having them available in the standard will be good.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This seems useful and the proposal seems solid to me</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Adds often needed functionality with apparently little to no overhead for read-and-conditional-store hardware.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>If it works it’s useful to have. I trust that it works.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’ve seen hand written implementations of this idea. The proposal standardizes the common practice.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a welcome addition that allows several platforms to utilize their hardware features.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’ve been convinced by the authors that this is necessary.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>For those cases where you want to do this, it makes it easy to do the efficient thing.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Having proposed atomic operations relieves developers from writing custom wrappers for generic execution contexts. I believe that vendors might do this job more efficiently.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This seems like a useful feature.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Closes the gap and creates the area for optimizations.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Adds often needed functionality with apparently little to no overhead for read-and-conditional-store hardware.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Standardizing existing practice in the domain seems to me like a good direction.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>A useful addition, that is hard for users to provide themselves.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Exposing atomic min and max as part of the C++ standard library enables far better implementations than users will do on their own, while being no less efficient at worst than the best user implementations.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Not really an area of my expertise, but this has direct mapping to some hardware.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Well-justified and useful addition.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Even though this seems niche and only really useful on a select few platforms, I’m happy to trust the proposers that this adds value.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>These operations are useful to a variety of applications and are not difficult to implement. The discussion about conditional stores was important but has reached a conclusion satisfactory to the experts.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Standardizes some already existing intrinsics, and gets a bit of a speed improvement. Hopefully the memory order issues don’t bite us, but even if they do, we can add new versions of the functions that take two memory order parameters.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Not terribly convinced by the motivation. Does this really provide enough benefit to spend our time on? The benchmark doesn’t seem very realistic to me.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>I have not participated in LEWG discussion around this topic and therefore feel that I should not vote.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>Too far removed from my area of expertise.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.4" id="poll-4"><span class="secno">3.4. </span><span class="content">Poll 4: <a data-link-type="biblio" href="https://wg21.link/p2286r6">[P2286R6]</a> Formatting Ranges</span><a class="self-link" href="#poll-4"></a></h3>
   <blockquote>
    <p>It is important to provide a solution in this space. We have a good bird in the hand.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>We need standard formatting for standard ranges</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a major improvement for formatting and a very useful feature.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I am excited to have this available</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Yes, please! A must-have feature!</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Makes it possible to format containers and ranges out of the box like in most other languages. Also adds string escaping which is super useful.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Almost every language has a good story for printing their equivalent of ranges. C++ direly needs this.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Finally. Everyone writes these, often badly, and often enough with visibility mistakes such that I’ve had ODR violations where I had to chase down multiple dependencies. The original argument for not having format operations on containers seems to have been disagreement about what that formatted output should look like, however the last several decades show that most people want essentially the same things, which formatting ranges provides.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Pretty important addition.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This feature is gravely needed and this paper gets it right.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’m happy with the reduction of the paper scope, I believe we made the right call. I love this paper, the ability to easily print ranges (and containers) is long overdue.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>
     The new specifiers are carefully designed. The debug-by-default output solves pain points. This paper also shows that it is unfortunate that parsing is coupled with formatting in 
     <format>. I also expect to see ellipsis output in the future.</format>
    </p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The ability to format all views is a top priority in the Ranges Plan for C++23 <a data-link-type="biblio" href="https://wg21.link/p2214r1">[P2214R1]</a>. I appreciate the authors' cross-language comparison. It took the author longer to implement printing the result of splitting a range in C++, than it did for the author to learn enough Go to write the same operation. I can do this thing trivially in Python. C++ has all the machinery to make this work; let’s get it done!</p>
    <p>The author carefully discusses the complications, including formatting filesystem::path.</p>
    <p>Section 3.9 does bring up the interesting point of proxy references, via vector of bool. This is relevant to <a data-link-type="biblio" href="https://wg21.link/p0009r14">[P0009R14]</a> (<code class="highlight"><c- n>mdspan</c-></code>), where the ability to define custom reference types is key to the design. The author’s solution (provide a format specialization for the proxy reference type) seems reasonable to me.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>We are missing a way to easily output the content on the ranges to the standard output. I like the direction of using a format specifier, as it allows quick customization of the behavior and matches the design of the library. The weakly favor vote, because I am not sure that supporting padding at cost of the potential allocation matches design principles of C++ - the user could format range separately in such case.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>It will be useful to many. I don’t see the existing situation as unsurmountable, but I agree this will be beneficial.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Should make "printf" debugging much nicer. Will certainly help those that want to format text for production reasons too.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>The lack of field experience worries me, but perhaps we can sometimes be bold.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Looks like a resonable syntax sugar.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Almost every other language provides default mechanism to print containers.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>While the capability is somewhat prescriptive, that sort of zero-configuration approach is appropriate for the especial contexts of debugging and log messages. The formatting choices are sensible given those purposes, and the few options provided are meaningful.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is something that has always been missing to output containers. I think this approach using format is probably the right one.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’m glad that the scope for this paper was reduced. The proposal fills a serious hole in std::format.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>No strong opinion on this, but the proposal looks good to me.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is an important feature that will have benefits for everyone using C++</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is an important missing piece of the formatting story. People expect standard containers and ranges to be formattable, just as they are in other languages. I am a little concerned that we’re moving this paper so late in the C++23 cycle, but the experts assure me it is ready.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I wish the range and debugging parts were separated, as I’m less enthusiastic about the later, but it looks okay now.
The Unicode part of string debugging is in the realm of "i can live with it", i have not yet convince my self it’s the right approach. This can be refined as long as no guarantee is made about the stability of these specifiers - if we can’t get that non-guarantee, I would change my vote to SA.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Gaps in the ability to format types are unfortunate. This paper brings tested functionality from fmt into the standard.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I personally don’t care much but I think the intention is good.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>Too complex for me to understand it fully in the current timeframe.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>I don’t sufficiently understand the topic to be able to vote in an informed manner.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>The paper has quite some issues and unspecified aspects discovered during review in the Text and Unicode study group.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.5" id="poll-5"><span class="secno">3.5. </span><span class="content">Poll 5: <a data-link-type="biblio" href="https://wg21.link/p2165r3">[P2165R3]</a> Compatibility Between <code class="highlight"><c- n>tuple</c-></code>, <code class="highlight"><c- n>pair</c-></code>, And <code class="highlight"><c- n>tuple</c-></code>-Like Objects</span><a class="self-link" href="#poll-5"></a></h3>
   <blockquote>
    <p>Author. This took a while but I think it is worth it :)</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Making tuple and pair more interoperable makes the library better.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I must admit there are some examples in there I thought compiled already but did not, so I’m sure this was confusing to more casual users. This will make theses types more useful.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a step towards making pair go away, and is thus worthwhile. The one breaking change is something I’ve never encountered in practice, despite having worked on several large code bases that use both tuple and pair.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a first stepping stone towards deprecating pair in user-code and removes cruft like "tuple-or-pair".</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I believe the paper will improve the uniformity of the design of the library.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I look forward to no longer having to accommodate both tuple and pair in generic code!</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is an extremely useful utility in certain use cases.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Being able to ignore <code class="highlight"><c- n>pair</c-></code> in new code is a worthwhile trade-off for the rare ambiguity due to <code class="highlight"><c- n>pair</c-></code> and <code class="highlight"><c- n>tuple</c-></code> being interconvertable.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a first stepping stone towards deprecating pair in user-code and removes cruft like "tuple-or-pair".</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This lack of interoperability has been annoying for a while. It would be good to make things less clunky.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Yes, this is something that I have wanted.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>An important building block (and necessary because we lack language level facilities here).</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Regularizing the language is important and makes it easier to use and teach C++.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This fixes a longstanding pain point with tuple/pair/tuple-like things. I’ve personally run into difficulties caused by the incompatibility between these morally equivalent things. I’m glad to see it finally fixed.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The incompatibility between tuple and pair can be a real pain.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This will make a number of things easier, and more straight forward so I am all for this.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>It is somewhat strange that a <code class="highlight"><c- n>__cpp_lib_tuple_like</c-></code> feature testing macro does not introduce the <code class="highlight"><c- n>tuple_like</c-></code> concept.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>OK. Even though it’s not appealing to make pair and tuple even more complex, this is perhaps a useful harmonization.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>From what I’ve heard we have this paper being implemented. On the other hand, I don’t understand all implications and could it potentially be breaking change for trickier scenarios.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>It’s a concerning change, since it could have confusing consequences, but there’s evidence that it should be okay. That would be a good result.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Seems useful but not earth shattering.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Useful consistency fix for the library.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is the bare minimum that we need for interop between these types.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I remain unconvinced that "make the use of std::pair unnecessary in new code" is a useful thing to do, but improving pair/tuple interop and avoiding the need for tuple-or-pair are useful things.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This goes a long way to providing one of the long needed language simplification and consistency features. Perhaps more consideration should be given to whether we do actually intend to eventually discourage the usage of pairs, or even deprecate them. I would also appreciate further assurance as to whether enough realistic implicit conversion scenarios have been tested for possible breakages. Overall in favor as this is indeed a long time in coming.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This does fix a long-standing problem/faq, although the amount of field experience or rather the lack of it is a bit disconcerting, but not overly so.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Good unification and simplification work.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I think reducing the scope to standard types reduces a lot of the uncertainty about the impact of the changes (the overload sets of these types is already hard to reason about), however, the benefits of this change is very limited (the only that I find useful is the array to tuple conversion).</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>Not sure that adding more implicit constructors to pair and tuple is a good idea.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>I don’t understand the pair-like and tuple-like requirements (e.g., exactly when user-defined types can qualify) well enough to judge how best to handle them in combination.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>Title sounds good, but didn’t read the paper.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>I’m ok with converting pair &lt;-> tuple, but converting between arrays &lt;-> tuples seems a special case</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>I think it would be far better to make tuple’s interface more pair-like, not the other way around. I’m very nervous about what this will break. The overload sets for pair and tuple are already a source of problems, and this looks like it will allow driving a truckload of new problems in.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.6" id="poll-6"><span class="secno">3.6. </span><span class="content">Poll 6: <a data-link-type="biblio" href="https://wg21.link/p2494r1">[P2494R1]</a> Relaxing Range Adaptors To Allow For Move Only Types</span><a class="self-link" href="#poll-6"></a></h3>
   <blockquote>
    <p>Can’t see any downsides to this.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is an important bug fix which enables new range adaptors like <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>repeat</c-></code>.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The paper will improve both the usability and the uniformity of the library.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This makes range adaptors more useful.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>No strong opinion on this, but the proposal looks good to me, and removing unnecessary constraints is something I think we should do in principle.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I consider this a fix to the standard library views, that were not updated to benefit from the relaxation of concept requirements.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Adding a missing link between two other relaxations we’ve made to range views.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a logical change of limited scope. It builds on the author’s experience proposing [<a data-link-type="biblio" href="https://wg21.link/p2474r1">[P2474R1]</a> <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>repeat</c-></code>, and it makes ranges more consistent.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is required to support move-only types in view::repeat, view:single, etc. which is a super useful thing to do.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This should really be a C++20 defect.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This relaxes an unnecessary restriction and make some adaptors a bit more useful.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Extends the useful and scope of ranges. Very useful.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Relaxing the constraints to allow views::single and the transform views to handle move-only types is reasonable.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>A must-have feature!</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Seems like one of those things that should be no brainers unless someone comes up with a serious objection. Only weakly in favor as I haven’t been involved in all the discussions.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I like seeing us embracing move only types in ranges more!</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Good addition to the Ranges library. What concerns me is that change is not backported to C++20.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>A useful relaxation of constraints, consistent with many other relaxations we’ve done recently.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Move only types are becoming common and this change is important to me.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Removing the requirement for copyability is a basic improvement that is correctly described as being in line with the removal of default constructibility. Neither is appropriate for this sort of generic code.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Fixing an oversight.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Seems a simple extension.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Support of move-only types is important.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I understand the need, appreciate the addition to the library, but cannot take a stronger stance due to insufficient personal use of ranges so far.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Looks like a highly useful fix.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Looks like it won’t hurt anything. I can live without it too though.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>This is range wizardry that I’m less comfortable voting on.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>I lack sufficient understanding of this topic to vote.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>No idea what this is about.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.7" id="poll-7"><span class="secno">3.7. </span><span class="content">Poll 7: <a data-link-type="biblio" href="https://wg21.link/p2322r5">[P2322R5]</a> <code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>fold</c-></code></span><a class="self-link" href="#poll-7"></a></h3>
   <blockquote>
    <p><code class="highlight"><c- n>fold</c-></code> is fundamental.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Fold is a core algorithm, and many other algorithms can be expressed in terms of fold, making it a good candidate for the standard library. I’m also happy with the results of the naming discussions, making the names unambiguous. This is important because many algorithm and PL texts use <code class="highlight"><c- n>fold</c-></code> to name the right fold, as it is the more general algorithm modelling general recursion, where left fold is primitive recursion. Of course the expressiveness of general recursion comes at a high cost and is why we are restricting it to bidirectional ranges so as to avoid surprising space leaks.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>+100</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I think we need a ranges fold. I don’t have a strong opinion about the finer details, but LEWG has given its input and the paper carefully justifies the author’s choices (culminating in Section 4.5). The author’s argument against projections (Section 4.6) makes sense.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a huge advance on std::accumulate.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p><code class="highlight"><c- n>fold</c-></code> is an essential algorithm</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I need this so thanks to the author.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Top priority tier 1 algorithm that is direly needed by ranges.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>It’s a shame we have so many names but it’s unavoidable and this is a very useful algorithm, with a better name that accumulate.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Non-commutative reductions are an important class of algorithms.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Reductions are an important and fundamental algorithmic primitive upon which many other algorithms are built. I’m glad we’ll finally have a range-based version, and one that fixes some of the historical mistakes of <code class="highlight"><c- n>accumulate</c-></code>/<code class="highlight"><c- n>reduce</c-></code>.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p><code class="highlight"><c- n>fold</c-></code> is an extremely common algorithm. The standard library should provide it.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I support having this algorithm included in the standard library</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>A very important algorithm.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>A good addition to ranges.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>One of the more useful new ranges additions, I think. It’s sufficiently general that it will find lots of uses.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a useful algorithm.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>No strong opinion on this, but the proposal looks good to me.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Fine new range algorithm.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>The names are good enough. Fold is also pretty fundamental in functional programming.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>It’s alright. I’m not crazy about the names, but a rose by any other name would smell as sweet. We need these algorithms.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>
     Short circuiting folds would have been great, but then neither does std::accumulate have short circuiting. Also, it’s about time we no longer have to explain why on earth we would need to include 
     <numeric> in order to concatenate a bunch of strings (just an illustrative example). The drawbacks of transform as a replacement for missing projections are regretful but not remotely enough to warrant delaying progress.</numeric>
    </p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Good addition to the Ranges library.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I think this will be a great addition, my only concern is that I’m not sure I see the usability of the iterator-returning overload.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is an extremely commonly used algorithm.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Very useful and basic algorithm. Weakly because I think that the proposed name(s) could be assigned to various algorithm versions in a more efficient manner.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I would like to use fold to motivate a change to how function sets are structured - but ultimately this should not block adoption in 23.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>Missed discussion, will not vote.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>Insufficient experience to comment.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>Not an expert.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>While <code class="highlight"><c- n>fold</c-></code> is obviously a basic functional programming component that we should support, I have not followed the discussion well enough to speak to the many design decisions taken by the paper.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.8" id="poll-8"><span class="secno">3.8. </span><span class="content">Poll 8: <a data-link-type="biblio" href="https://wg21.link/p2302r2">[P2302R2]</a> <code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>contains</c-></code></span><a class="self-link" href="#poll-8"></a></h3>
   <blockquote>
    <p>Any other vote would seem off :-)</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p><code class="highlight"><c- n>contains</c-></code> is an essential algorithm.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is an extremely commonly used algorithm.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Containment questions come up very often. The single element version is reasonably straightforward to write by most programmers without an external reference at hand. The subrange version is not, and doing so correctly and efficiently was a major study topic in early algorithm research. We have good solutions now, but including them in the standard will prevent needless creativity around a common problem. This is a good candidate for a standard library component.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Usability improvement for some users.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>(counts the years) 24 years too late.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Clearly warranted given the obvious benefit to language simplification, and no apparent risks.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is an important algorithm for better expressing intent over "find".</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p><code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>contains</c-></code> is a useful shortcut. I’m OK with "contains" (the more commonly used case) meaning "contains an element" and "contains_subrange" (the less commonly used case) meaning "contains a subrange."  I’m also OK with the author’s choice of parameter order (see Section 4.3).</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Very useful algorithm that should definitely be adding. Follows up to the member functions on specific containers.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a commonly needed algorithm.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I support having this algorithm included in the standard library.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Seems like a basic algorithm, we should have had it in C++20.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Very useful algorithm wrapper to the find, that makes it a lot more ergonomic to use (especially in presence of range algorithms, that does not pass begin/end).</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a very common thing to want to do, and contains is simply easier to read and write than find != end.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Good addition that simplifies certain patterns.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Small QoL improvement hooray!</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>A useful shorthand for a common operation, trivial to specify and improves ergonomics.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>A good addition to ranges.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Useful, expressively named algorithm.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>An obvious addition that we should have in the library</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p><code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>contains</c-></code> in particular has the useful property of avoiding the need to repeat an argument, so that it’s helpful for computed ranges. It’s unfortunate that <code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>contains_subrange</c-></code> provides no access to searchers like Boyer-Moore, but that’s no more true than for <code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>search</c-></code>.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Useful algorithm which is valuable to add.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Good addition to the Ranges library.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This seems like a straightforward addition. I’m not sure I buy the author’s argument that everyone should be using this over member <code class="highlight"><c- n>contains</c-></code>, but still, this is nice to have.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>No idea what this is about.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>I was not involved in the discussion.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>Did not pay enough attention to the proposal.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.9" id="poll-9"><span class="secno">3.9. </span><span class="content">Poll 9: <a data-link-type="biblio" href="https://wg21.link/p1899r2">[P1899R2]</a> <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>stride</c-></code></span><a class="self-link" href="#poll-9"></a></h3>
   <blockquote>
    <p>Just another useful view.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I believe this is useful, and increasing the amount of ranges utilities is a top priority.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This adaptor is sorely needed; many applications can do little better without it than fall back to indices with views::iota | views::transform. The proper support for random access satisfies the guideline that standard library facilities not be trivial to implement.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I agree with the authors that this is overdue and that user-written alternatives would tend to be problematic.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Another useful and important range adaptor. This is particularly important when dealing with multi-dimensional data or vectorization, when you want to be able to take a slice of a range.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is an often-needed facility</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a very useful tool I’ve wished for many times.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Very useful anamorphic/unfold algorithm that should be added to ranges.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Any other vote would seem off :-)</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is an important feature (along with iota and cartesian_product) for constructing multidimensional index ranges. It also protects users from the ill-formed-diagnostic-not-required pitfall of trying to implement a strided range using filter_view. I appreciate that the proposal implements a random-access range adapter; this will make it easier to reason about composing multidimensional index ranges.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Definitely a much needed extension, as well as a prevention means of dangerous code. I see no objections raised so I’m all in.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is an important range adaptor for which there is plenty of implementation/usage experience.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Strided access is a basic functionality that is sorely missing from the standard.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This significantly simplifies iterating over a range with a stride, which is an extremely common operation.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Striding through containers is super useful.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Stride algorithms are common, and expressed easily as for loops. They ought to be expressible as views and range algorithms. This allows it, finally.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>No strong opinion on this, but the proposal looks good to me.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Good addition to the Ranges library.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Having views::stride is an essential addition to cooperative execution contexts which benefit from coalesced loads.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Useful view, with good motivation.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I could live without it, but there are uses for it</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>A useful range adaptor.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’m not familiar enough with the proposal to vote on it.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>Haven’t paid attention to the discussion on this paper, and haven’t looked hard at the paper.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.10" id="poll-10"><span class="secno">3.10. </span><span class="content">Poll 10: <a data-link-type="biblio" href="https://wg21.link/p2474r1">[P2474R1]</a> <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>repeat</c-></code></span><a class="self-link" href="#poll-10"></a></h3>
   <blockquote>
    <p>Part way between <code class="highlight"><c- n>single</c-></code> and <code class="highlight"><c- n>iota</c-></code>, having a repeating element comes up frequently enough that having it as a primitive is useful.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Another very useful algorithm that should be added to ranges.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a nice convenience for some linear algebra algorithms.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is another useful view.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This facility is yet another useful means of avoiding the views::iota | views::transform dance. Having another unbounded range is somewhat problematic given the existing defects in dealing with such ranges, but perhaps having another useful example of such will serve as motivation to address those.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I will use this and agree with the author about the general need for this feature.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Good addition to the Ranges library.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I believe this is useful, and increasing the amount of ranges utilities is a top priority.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a very useful view factory.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is often needed.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>In Thrust, we have a similar facility called <code class="highlight"><c- n>constant_iterator</c-></code>, which is used pervasively. I’m glad to finally have a standard version of this abstraction - it will allow even more parallel patterns to be expressed using ranges and the execution-based parallel algorithms.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a very useful tool I’ve wished for many times.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This view becomes a lot more useful with the introduction of the zip.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>More convenient to spell than <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>cartesian_product</c-><c- p>(</c-><c- n>iota</c-><c- p>(</c-><c- mi>0</c-><c- p>),</c-> <c- n>views</c-><c- o>::</c-><c- n>single</c-><c- p>(</c-><c- n>n</c-><c- p>))</c-> <c- o>|</c-> <c- n>views</c-><c- o>::</c-><c- n>values</c-><c- p>;</c-></code>, and useful view in some cases</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p><code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>repeat</c-></code> is a useful feature. I could see myself using it with <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>zip</c-></code> and <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>cartesian_product</c-></code>. I also appreciate how the authors avoided the data race in generate, by defining <code class="highlight"><c- n>repeat_view</c-></code> in a similar way to <code class="highlight"><c- n>iota_view</c-></code>.</p>
    <p>I’m not a Library wording expert, but <a data-link-type="biblio" href="https://wg21.link/p2494r1">[P2494R1]</a> and <a data-link-type="biblio" href="https://wg21.link/p2474r1">[P2474R1]</a> (<code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>repeat</c-></code>) might need some wording to indicate the order of application (<a data-link-type="biblio" href="https://wg21.link/p2474r1">[P2474R1]</a> first, then <a data-link-type="biblio" href="https://wg21.link/p2494r1">[P2494R1]</a>).</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’m not super clear on the real world utility of this, but it seems pretty harmless. Others seem to find it useful though, so I won’t get in the way.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p><code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>repeat</c-></code> provides a critical building block that, combined with other views, enrich the expressiveness of the standard ranges.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>A good addition to ranges.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I could live without it, but there are uses for it.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>No strong opinion on this, but the proposal looks good to me.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’m sensing some lack of proper discussion regarding the implications of the decisions taken in section 4.3, namely lack of support for move-only types and opting for repeat_view to not be a borrowed range. I would prefer to have a deeper understanding of those aspects. Overall in favor.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Did not follow the discussion of this paper closely enough.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>Haven’t followed the paper.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.11" id="poll-11"><span class="secno">3.11. </span><span class="content">Poll 11: <a data-link-type="biblio" href="https://wg21.link/p2508r1">[P2508R1]</a> Expose <code class="highlight"><c- n>basic</c-><c- o>-</c-><c- n>format</c-><c- o>-</c-><c- n>string</c-><c- o>&lt;</c-><c- n>charT</c-><c- p>,</c-> <c- n>Args</c-><c- p>...</c-><c- o>></c-></code></span><a class="self-link" href="#poll-11"></a></h3>
   <blockquote>
    <p>The standard formatting facilities always provided a way for the user to write their own formating functions, and we should make the formatting functions available to it.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This proposal just names a thing that already exists in implementations. This change is much easier than the language changes (constexpr function parameters, or hygienic macros) that would otherwise be needed.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Very useful feature for custom loggers and format based wrappers.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>A very simple change that makes it much easier for users to write formatting functions with compile-time format string checks.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I wish we could’ve done this immediately when shipping the previous change.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>
     I consider the exposure of the (tentatively) mandated feature of compile-time format-string checking highly useful. It will be most likely already present in a similar way in an implementation of 
     <format> so providing it to clients of the standard library should be a no-brainer. I’m currently experimenting with MSVC’s implementation of _Basic_format_string in a totally different use-case other than those mentioned in <a data-link-type="biblio" href="https://wg21.link/p2508r1">[P2508R1]</a>. There it would be highly desirable to provide the functionality and safety net to users without reimplementing the same machinery by myself.</format>
    </p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Taken from Barry: "... catching bugs at compile time is awesome ...".</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>We added this functionality for the standard library, but users might need it too. It’s a trivial extension, so we should do it. We didn’t do it originally because we thought we might add a language feature to help out, but we didn’t, so... we should do this.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The compile-time checking of format strings is one of the main features of std::format overall. Failing to expose it is an own goal, and no "constexpr function parameter" or equivalent that would (in some cases) obviate the need is anywhere near realization.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Adding the ability to forward format_strings enables additional use cases that are currently not possible without forgoing compile-time checking - and as Barry puts it: "catching bugs at compile time is awesome".</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Making it possible for users to wrap calls to std::format is important for many uses.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The case of being able to statically check my log statements is compelling. It’s clear why this was exposition only initially, but there are too many reasons it ought to be available outside the std library.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This will find bugs at compile time.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is highly necessary otherwise it will be much harder to write efficient "front-ends" for formated output.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Any apparently-risk-free new feature that pushes error detection from runtime to compile time is definitely good news.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Change is required to make format usable for important use-cases.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Where reasonable, the stdlib shouldn’t be in a privileged position. This paper helps address that.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>No strong opinion on this, but the proposal looks good to me.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This seems like a straightforward and simple addition.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This seems like a useful facility.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’m convinced by the motivation to have this, and I believe it’s best to provide by the standard library</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I like compile-time errors and I do not like rewriting facilities.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’m a bit worried about exposing this without any field experience, but not overly so.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>OK, I guess.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>I was not part of the discussion.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>I haven’t studied this paper.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.12" id="poll-12"><span class="secno">3.12. </span><span class="content">Poll 12: <a data-link-type="biblio" href="https://wg21.link/p2248r4">[P2248R4]</a> Enabling List-Initialization For Algorithms</span><a class="self-link" href="#poll-12"></a></h3>
   <blockquote>
    <p>We should do this.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Simple fix, but effective.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This proposal increases Standard Library usability. It may break ABI, but I don’t think it’s reasonable to rely on ABI stability for Standard Algorithms.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>As a C++ user, I strongly favor this proposal that reduces verbosity when using the standard library. I find the arguments around API &amp; ABI compatibility questions reasonable and convincing.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>A small change that improves usability a lot.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This seems like a good quality-of-life improvement, but I am a bit apprehensive that we might be giving up syntax space by making this implicit.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>🤷‍♀️ Not sure it’s all that great but sure, why not!</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’m not a huge fan for list-initializers, but this at least makes a facility somewhat more consistent, an no less clear in use.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>A nice quality of life improvement.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Supporting untyped braces as arguments makes it really hard to evolve an overload set (see the ridiculous hoops basic_string had to jump through), but it seems a bit unlikely that we’ll add new overloads to the existing algorithms.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This proposal is important for improving language ease of use and potentially eliminating one source of DRY violations (always a good thing). Some of the limitations imposed due to parameter ordering issues could be revised in the future should D2288 (designated arguments) make it into the standard.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I find this a good fix to improve our support for a programming style where braces are used instead of mentioning types.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Just fine fix for the ergonomy of the usage of the algorithm.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Somewhat useful extension of algorithms.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Seems to me this will simplify code and I see no issues with deducing the type in this case.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>On one hand it simplifies the usage of the algorithm, on the other hand, it might cause less readable code. If people believe it’s useful I don’t want to create obstacles thus, I am Weakly in Favor, but very weakly.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Simplifies some patterns which is useful.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Reduces the need for unnecessary type declarations. Some concerns about a potential ABI breaks remain.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>A very useful feature, though I’m bellyaching about the ABI thing (despite SD-8).</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>A nice usability improvement for the algorithms.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Meh. OK.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>The number of "surely compatible in every case we care about" changes here is a bit concerning, but the underlying principles are sound and cause the library to be less surprising on the whole. It’s also unfortunate, of course, that SG6 is completely absent and cannot provide feedback on the choices made for the numerical algorithms, but those choices do not seem complicated or controversial.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>For exchange in particular, not having this has been unpleasant for a while now.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Fine with me, but I’m a bit underconvinced this is important enough.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>Not sure we need this enough to spend our time on it.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>Seems useful but I worry about whether it makes it easier for users to make errors.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>It looks okay, but I’m not sure I find the paper very compelling.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>I’m pretty conflicted on this. It’s occasionally nice, but I’m not sure it’s really important.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>Not sure if the addition improves the code readability.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>I’ve glanced over the paper, but not enough to dig into its subtleties. I think it’s the right direction, but the wording  needs to be cleaned up.</p>
    <p>Abstaining since I haven’t given it enough attention.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>Sound good, but didn’t read the paper.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>I’m not familiar enough with the proposal to vote on it.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.13" id="poll-13"><span class="secno">3.13. </span><span class="content">Poll 13: <a data-link-type="biblio" href="https://wg21.link/p2404r2">[P2404R2]</a> Move-Only Types For <code class="highlight"><c- n>equality_comparable_with</c-></code>, <code class="highlight"><c- n>totally_ordered_with</c-></code>, And <code class="highlight"><c- n>three_way_comparable_with</c-></code></span><a class="self-link" href="#poll-13"></a></h3>
   <blockquote>
    <p>Regularizing the language is important and makes it easier to use and teach C++.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Feels more like a bug fix rather than a new feature.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I think the paper increases the cohesion between the mathematical "equality" concept and the language one.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I agree with the reasoning in this paper.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>A good fix for this unnecessary lack of functionality.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>While it’s unfortunate to introduce yet more prose describing the questionable semantic requirements for the consistency of comparisons and orderings, changes that reduce the artificial nature of those requirements are still good news. More generally, the library concepts should not be unduly interested in copying, especially in contexts where there is never any reason to actually do so at runtime.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Despite my original reservations of this paper, I’ve been convinced it’s an inclusive-only change.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This change to the concept goes in the right direction, but I believe should be taken further, to allow opt-in into heterogeneous comparison without the presence of the common type, but that change can be applied on top of the paper.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This cleans up the implicit emergent typesystem of C++ in a useful way. The case of <code class="highlight"><c- n>equality_comparable_with</c-><c- o>&lt;</c-><c- n>unique_ptr</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-><c- p>,</c-> <c- n>nullptr_t</c-><c- o>></c-></code> being false is an indication that something has gone awry with our type classifiers. Reformulating with a supertype requirement, rather than the common reference requirement, solves this problem.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a useful incremental improvement of the existing design.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Should have been properly specified from the get-go, this fixes it.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Another data point calling into question the value of common_reference.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I appreciate the usability, but I’m not sure if I understand all the issues.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Good job on the part of the author. The possible breakages seem reasonable and it’s a good idea to proceed now as there are probably not many such cases "in the wild" yet.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I consider this a bug fix.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>No strong opinion on this, but the proposal looks good to me.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Good cleanup.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>The proposal seems to have its homework done astonishingly well. The amount of field experience is worrying, but not overly so.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This looks good but it would make zero sense not to apply it as a DR if we move forward with this, I hope we do. It would not impact ABI, so there is very little reason not to.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Seems reasonable, no strong opinion.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>I think this is good, but changing these scares me a bit.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>Too complex for me to understand it fully in the current timeframe.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>Did not pay enough attention to the proposal.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>Not sure I had enough time to read and understand all corner cases. Seems like people don’t want to backport it to C++20, which is a little bit concerns me.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.14" id="poll-14"><span class="secno">3.14. </span><span class="content">Poll 14: <a data-link-type="biblio" href="https://wg21.link/P2502R1">[P2502R1]</a> <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>generator</c-></code></span><a class="self-link" href="#poll-14"></a></h3>
   <blockquote>
    <p>This is a solid and minimal design. Now that we’ve reached consensus on the reference type for the <code class="highlight"><c- n>generator</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code> case, I thin k this is ready to go. I’ll be glad to have this in C++23 so I can stop writing my own.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The recursive generator type shows up distressingly often, so it needs to be addressed, and this type does with minimal extra overhead while having a single generator type. Library types, even those intended to be very generic, are unfortunately used in interfaces, so having a generator that can be used recursively, in for example the sort standard example, is of definite value. This probably does preclude having a more efficient recursive generator in this space, but it doesn’t preclude one from being written.
I would have preferred to see a task/lazy and a memo type to cover the 90% space for coroutines, but time and tide wait for no one, and we ship.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The lack of generators that use the C++20 coroutine model is a sore spot with developers. This paper fills the need.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Having done a little bit of trying to work with C++ coroutines, I’m disappointed so far in how few library facilities we’ve added that actually help you with them. The pitch was that most people just write coroutines and very, very few people have to write coroutine machinery — but in practice everyone has to write coroutine machinery, because there isn’t any, which completely inverts the complexity of this feature. You can’t just have a tutorial demonstrating how to use <code class="highlight"><c- n>generator</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code>, because there is no <code class="highlight"><c- n>generator</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code> — you have to start by teaching people how to implement <code class="highlight"><c- n>generator</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code>. Imagine what people’s impressions of <code class="highlight"><c- o>&lt;</c-><c- n>algorithm</c-><c- o>></c-></code> would be if step one was implement std::vector from scratch, including custom iterators.</p>
    <p>All of which is to say: this is a very important addition to the library, but we need way way more, and I think it says something about our process that we are basically barely getting even this.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>We really want a generator type for C++23. generator is an important vocabulary type that will make it easier for libraries that use coroutines to work together. Libraries are already being written that use C++20 coroutines (we have one), so it’s important to have vocabulary types like generator as soon as possible.</p>
    <p>There are three questions to discuss.</p>
    <ol>
     <li data-md>
      <p>Should recursive yielding work?</p>
     <li data-md>
      <p>Should we permit <code class="highlight"><c- n>generator</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code> with T being a nonreference type?</p>
     <li data-md>
      <p>If so, what should the reference type of <code class="highlight"><c- n>generator</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code> be?</p>
    </ol>
    <p>Regarding (1), I think the recursive case is useful, and it would be surprising to most users if it didn’t work. It would be unfortunate if a vocabulary type like "generator" forbade recursive calls. If the nonrecursive case matters for performance in special cases, then users still have the option to write a custom "nonrecursive_generator."  This is in line with the C++ coroutines design that permits customization of the return type.</p>
    <p>Question (2) refers to the so-called "nuclear option": if we couldn’t agree whether the default reference type (see Question (3)) should be <code class="highlight"><c- k>const</c-> <c- n>T</c-><c- o>&amp;</c-></code> or <code class="highlight"><c- n>T</c-><c- o>&amp;&amp;</c-></code>, then we should just forbid nonreference types. My view is that generator is useful enough as a vocabulary type, that I would rather we took the "nuclear option" than not have generator at all for C++23. However, during the last LEWG discussion of generator in January 2022, enough of the (virtual) room favored <code class="highlight"><c- n>T</c-><c- o>&amp;&amp;</c-></code> over const T&amp; as the default reference type, that the "nuclear option" no longer appeared necessary.</p>
    <p>Regarding (3), I’m still a bit uncomfortable about the <code class="highlight"><c- n>T</c-><c- o>&amp;&amp;</c-></code> default reference type. There’s no precedence in current generator implementations (including our own) for this choice. However, <a data-link-type="biblio" href="https://wg21.link/P2529R0">[P2529R0]</a> makes a good argument that <code class="highlight"><c- n>T</c-><c- o>&amp;&amp;</c-></code> matches the one-pass-only guarantee of generator, and that it’s no less safe than <code class="highlight"><c- k>for</c-><c- p>(</c-><c- k>auto</c-><c- o>&amp;&amp;</c-> <c- nl>x</c-> <c- p>:</c-> <c- n>f</c-><c- p>())</c-></code>. Users also have the option to set the reference type themselves. A code base could decide to use an alias that insists on <code class="highlight"><c- k>const</c-> <c- n>T</c-><c- o>&amp;</c-></code> or even <code class="highlight"><c- n>T</c-></code> for the reference type. Thus, generator could still be a useful vocabulary type with this default.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>A missing piece of C++20.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The feature was requested multiple times by users.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Ship it! We need this in the standard library.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Even more undesirable than shipping C++23 without any actual asynchronous coroutine support types would be to ship it without the one obvious type for synchronous use cases (which are applicable to a wider range of domains). A heroic effort has produced an interpretation of reference and recursion semantics that managed to gain consensus, to which further discussion would not be likely to add much.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a killer feature for using coroutines.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I think std::generator is a critical part of completing the coroutines story in Standard C++.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>It’s of utmost importance that we improve the usability story of coroutines in C++23.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>An important component that makes coroutines usable in the first place.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Looks very practical and rich in features. Glad to see C++23 with synchronized generators. That’s a lot of voids, but mostly due to the language restrictions.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>should be a must-have for C++23</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is an important vocabulary type that allows usage of coroutines in more scenarios.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This type is necessary and the design is good.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>We need proper coroutine support in the standard library. This is a start.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>It’s unclear to me why I want a generator, but its proponents seem to make a good-enough case for it.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>We need something like this to deliver the benefits of coroutines.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>No strong opinion on this, but the proposal looks good to me.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Coroutine support is important for the library. At this stage, we should maximize chances of having it.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>The main area of contention on this paper is the defaults. Either set of discussed defaults will be ok, and we can always be explicit when needed.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Looks good.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Grinding my teeth on this one, both as a committee newbie and also in light of the recent intensive deliberations, especially in <a data-link-type="biblio" href="https://wg21.link/P2529R0">[P2529R0]</a>. Mental modeling of this kind of issues seems to me to be made harder by the fact that it makes sense indeed to view yielding as similar to both argument passing and returning from a function - however the former makes sense only from the point of view of the coroutine implementer, and the latter only from the pov of its consumer. Finding the middle ground between these two different approaches is what is making this so hard. Overall I find it hard to imagine any long term negative impact stemming from taking the wrong decisions now that would be worse than releasing one more C++ standard without coroutine standard library support and all the divergence that would likely cause in the community (or alternatively delays in widespread coroutine usage in production code), so I say let’s cautiously move this forward.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I hope this will alleviate users who currently need to write these by hand. The design seems sound to me.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>We have agreement on all the design issues and only need one fix paper to go through LEWG to disable yielding lvalues for <code class="highlight"><c- n>generator</c-><c- o>&lt;</c-><c- n>T</c-><c- o>&amp;&amp;></c-></code>, which will be written and should prove uncontentious.</p>
    <p>It’s the right design, so I’m for including it in the WD.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I want this, but I haven’t had a chance to read the paper in a while.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>I have not participated in LEWG discussion around this topic and therefore feel that I should not vote.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>I believe that the <code class="highlight"><c- n>generator</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code> will be a type that will be very popular, second to the <code class="highlight"><c- n>vector</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code>. In that situation, I think picking the behavior of returning <code class="highlight"><c- n>T</c-><c- o>&amp;&amp;</c-></code>, while providing optimization benefits, will lead to hard to debug bugs for the user, that were not exposed to such ranges before (i.e. used move_iterator frequently). Forgetting to move the object, is not program breaking mistake, compared to the possibility of double move.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>I still believe we are making a mistake here: defaulting to rvalues is a performance trap on the producer side (copying lvalues silently when there should be no reason to!), and a foot gun on the client side (Functions returning rvalue ref in general require care and "well, in these handpicked scenarios it’s a non-issue" is not a great argument: This was supposed to be a class for non-expert.</p>
    <p>Having played with many implementations strategies, I’m still not super happy with the effect of exception_ptr on code gen,</p>
    <p>I hope I’m wrong, it’s an important class to get right!</p>
    <p>We are sacrificing performance for usability and safety for performance (assuming no lvalues). It is not a self consistent design.</p>
    <p>— Strongly Against</p>
   </blockquote>
  </main>
<script>
(function() {
  "use strict";
  var collapseSidebarText = '<span aria-hidden="true">←</span> '
                          + '<span>Collapse Sidebar</span>';
  var expandSidebarText   = '<span aria-hidden="true">→</span> '
                          + '<span>Pop Out Sidebar</span>';
  var tocJumpText         = '<span aria-hidden="true">↑</span> '
                          + '<span>Jump to Table of Contents</span>';

  var sidebarMedia = window.matchMedia('screen and (min-width: 78em)');
  var autoToggle   = function(e){ toggleSidebar(e.matches) };
  if(sidebarMedia.addListener) {
    sidebarMedia.addListener(autoToggle);
  }

  function toggleSidebar(on) {
    if (on == undefined) {
      on = !document.body.classList.contains('toc-sidebar');
    }

    /* Don’t scroll to compensate for the ToC if we’re above it already. */
    var headY = 0;
    var head = document.querySelector('.head');
    if (head) {
      // terrible approx of "top of ToC"
      headY += head.offsetTop + head.offsetHeight;
    }
    var skipScroll = window.scrollY < headY;

    var toggle = document.getElementById('toc-toggle');
    var tocNav = document.getElementById('toc');
    if (on) {
      var tocHeight = tocNav.offsetHeight;
      document.body.classList.add('toc-sidebar');
      document.body.classList.remove('toc-inline');
      toggle.innerHTML = collapseSidebarText;
      if (!skipScroll) {
        window.scrollBy(0, 0 - tocHeight);
      }
      tocNav.focus();
      sidebarMedia.addListener(autoToggle); // auto-collapse when out of room
    }
    else {
      document.body.classList.add('toc-inline');
      document.body.classList.remove('toc-sidebar');
      toggle.innerHTML = expandSidebarText;
      if (!skipScroll) {
        window.scrollBy(0, tocNav.offsetHeight);
      }
      if (toggle.matches(':hover')) {
        /* Unfocus button when not using keyboard navigation,
           because I don’t know where else to send the focus. */
        toggle.blur();
      }
    }
  }

  function createSidebarToggle() {
    /* Create the sidebar toggle in JS; it shouldn’t exist when JS is off. */
    var toggle = document.createElement('a');
      /* This should probably be a button, but appearance isn’t standards-track.*/
    toggle.id = 'toc-toggle';
    toggle.class = 'toc-toggle';
    toggle.href = '#toc';
    toggle.innerHTML = collapseSidebarText;

    sidebarMedia.addListener(autoToggle);
    var toggler = function(e) {
      e.preventDefault();
      sidebarMedia.removeListener(autoToggle); // persist explicit off states
      toggleSidebar();
      return false;
    }
    toggle.addEventListener('click', toggler, false);


    /* Get <nav id=toc-nav>, or make it if we don’t have one. */
    var tocNav = document.getElementById('toc-nav');
    if (!tocNav) {
      tocNav = document.createElement('p');
      tocNav.id = 'toc-nav';
      /* Prepend for better keyboard navigation */
      document.body.insertBefore(tocNav, document.body.firstChild);
    }
    /* While we’re at it, make sure we have a Jump to Toc link. */
    var tocJump = document.getElementById('toc-jump');
    if (!tocJump) {
      tocJump = document.createElement('a');
      tocJump.id = 'toc-jump';
      tocJump.href = '#toc';
      tocJump.innerHTML = tocJumpText;
      tocNav.appendChild(tocJump);
    }

    tocNav.appendChild(toggle);
  }

  var toc = document.getElementById('toc');
  if (toc) {
    createSidebarToggle();
    toggleSidebar(sidebarMedia.matches);

    /* If the sidebar has been manually opened and is currently overlaying the text
       (window too small for the MQ to add the margin to body),
       then auto-close the sidebar once you click on something in there. */
    toc.addEventListener('click', function(e) {
      if(e.target.tagName.toLowerCase() == "a" && document.body.classList.contains('toc-sidebar') && !sidebarMedia.matches) {
        toggleSidebar(false);
      }
    }, false);
  }
  else {
    console.warn("Can’t find Table of Contents. Please use <nav id='toc'> around the ToC.");
  }

  /* Wrap tables in case they overflow */
  var tables = document.querySelectorAll(':not(.overlarge) > table.data, :not(.overlarge) > table.index');
  var numTables = tables.length;
  for (var i = 0; i < numTables; i++) {
    var table = tables[i];
    var wrapper = document.createElement('div');
    wrapper.className = 'overlarge';
    table.parentNode.insertBefore(wrapper, table);
    wrapper.appendChild(table);
  }

})();
</script>
  <h2 class="no-num no-ref heading settled" id="references"><span class="content">References</span><a class="self-link" href="#references"></a></h2>
  <h3 class="no-num no-ref heading settled" id="informative"><span class="content">Informative References</span><a class="self-link" href="#informative"></a></h3>
  <dl>
   <dt id="biblio-p0009r14">[P0009R14]
   <dd>Christian Trott, D.S. Hollman, Damien Lebrun-Grandie, Mark Hoemmen, Daniel Sunderland, H. Carter Edwards, Bryce Adelstein Lelbach, Mauro Bianco, Ben Sander, Athanasios Iliopoulos, John Michopoulos, Nevin Liber. <a href="https://wg21.link/p0009r14"><cite>MDSPAN</cite></a>. 15 November 2021. URL: <a href="https://wg21.link/p0009r14">https://wg21.link/p0009r14</a>
   <dt id="biblio-p0443r14">[P0443R14]
   <dd>Jared Hoberock, Michael Garland, Chris Kohlhoff, Chris Mysen, H. Carter Edwards, Gordon Brown, D. S. Hollman. <a href="https://wg21.link/p0443r14"><cite>A Unified Executors Proposal for C++</cite></a>. 15 September 2020. URL: <a href="https://wg21.link/p0443r14">https://wg21.link/p0443r14</a>
   <dt id="biblio-p0493r3">[P0493R3]
   <dd>Al Grant, Bronek Kozicki, Tim Northover. <a href="https://wg21.link/p0493r3"><cite>Atomic maximum/minimum</cite></a>. 18 December 2021. URL: <a href="https://wg21.link/p0493r3">https://wg21.link/p0493r3</a>
   <dt id="biblio-p0592r4">[P0592R4]
   <dd>Ville Voutilainen. <a href="https://wg21.link/p0592r4"><cite>To boldly suggest an overall plan for C++23</cite></a>. 25 November 2019. URL: <a href="https://wg21.link/p0592r4">https://wg21.link/p0592r4</a>
   <dt id="biblio-p1000r4">[P1000R4]
   <dd>Herb Sutter. <a href="https://wg21.link/p1000r4"><cite>C++ IS schedule</cite></a>. 14 February 2020. URL: <a href="https://wg21.link/p1000r4">https://wg21.link/p1000r4</a>
   <dt id="biblio-p1899r2">[P1899R2]
   <dd>Christopher Di Bella, Tim Song. <a href="https://wg21.link/p1899r2"><cite>stride_view</cite></a>. 23 December 2021. URL: <a href="https://wg21.link/p1899r2">https://wg21.link/p1899r2</a>
   <dt id="biblio-p2000r3">[P2000R3]
   <dd>Daveed Vandevoorde, Howard Hinnant, Roger Orr, Bjarne Stroustrup, Michael Wong. <a href="https://wg21.link/p2000r3"><cite>Direction for ISO C++</cite></a>. 6 January 2022. URL: <a href="https://wg21.link/p2000r3">https://wg21.link/p2000r3</a>
   <dt id="biblio-p2079r2">[P2079R2]
   <dd>Lee Howes, Ruslan Arutyunyan, Michael Voss. <a href="https://wg21.link/p2079r2"><cite>System execution context</cite></a>. 15 January 2022. URL: <a href="https://wg21.link/p2079r2">https://wg21.link/p2079r2</a>
   <dt id="biblio-p2165r3">[P2165R3]
   <dd>Corentin Jabot. <a href="https://wg21.link/p2165r3"><cite>Compatibility between tuple, pair and tuple-like objects</cite></a>. 18 January 2022. URL: <a href="https://wg21.link/p2165r3">https://wg21.link/p2165r3</a>
   <dt id="biblio-p2214r1">[P2214R1]
   <dd>Barry Revzin, Conor Hoekstra, Tim Song. <a href="https://wg21.link/p2214r1"><cite>A Plan for C++23 Ranges</cite></a>. 14 September 2021. URL: <a href="https://wg21.link/p2214r1">https://wg21.link/p2214r1</a>
   <dt id="biblio-p2248r4">[P2248R4]
   <dd>Giuseppe D'Angelo. <a href="https://wg21.link/p2248r4"><cite>Enabling list-initialization for algorithms</cite></a>. 3 January 2022. URL: <a href="https://wg21.link/p2248r4">https://wg21.link/p2248r4</a>
   <dt id="biblio-p2286r6">[P2286R6]
   <dd>Barry Revzin. <a href="https://wg21.link/p2286r6"><cite>Formatting Ranges</cite></a>. 19 January 2022. URL: <a href="https://wg21.link/p2286r6">https://wg21.link/p2286r6</a>
   <dt id="biblio-p2300r4">[P2300R4]
   <dd>Michał Dominiak, Lewis Baker, Lee Howes, Kirk Shoop, Michael Garland, Eric Niebler, Bryce Adelstein Lelbach. <a href="https://wg21.link/p2300r4"><cite>std::execution</cite></a>. 19 January 2022. URL: <a href="https://wg21.link/p2300r4">https://wg21.link/p2300r4</a>
   <dt id="biblio-p2302r2">[P2302R2]
   <dd>Christopher Di Bella. <a href="https://wg21.link/p2302r2"><cite>std::ranges::contains</cite></a>. 12 December 2021. URL: <a href="https://wg21.link/p2302r2">https://wg21.link/p2302r2</a>
   <dt id="biblio-p2322r5">[P2322R5]
   <dd>Barry Revzin. <a href="https://wg21.link/p2322r5"><cite>ranges::fold</cite></a>. 18 October 2021. URL: <a href="https://wg21.link/p2322r5">https://wg21.link/p2322r5</a>
   <dt id="biblio-p2363r3">[P2363R3]
   <dd>Konstantin Boyarinov, Sergey Vinogradov, Ruslan Arutyunyan. <a href="https://wg21.link/p2363r3"><cite>Extending associative containers with the remaining heterogeneous overloads</cite></a>. 19 January 2022. URL: <a href="https://wg21.link/p2363r3">https://wg21.link/p2363r3</a>
   <dt id="biblio-p2404r2">[P2404R2]
   <dd>Justin Bassett. <a href="https://wg21.link/p2404r2"><cite>Move-only types for equality_comparable_with, totally_ordered_with, and three_way_comparable_with</cite></a>. 19 January 2022. URL: <a href="https://wg21.link/p2404r2">https://wg21.link/p2404r2</a>
   <dt id="biblio-p2458r1">[P2458R1]
   <dd>Bryce Adelstein Lelbach. <a href="https://wg21.link/P2458R1"><cite>2022 January Library Evolution Polls</cite></a>. 2022-01-26. URL: <a href="https://wg21.link/P2458R1">https://wg21.link/P2458R1</a>
   <dt id="biblio-p2474r1">[P2474R1]
   <dd>Michał Dominiak. <a href="https://wg21.link/p2474r1"><cite>views::repeat</cite></a>. 18 January 2022. URL: <a href="https://wg21.link/p2474r1">https://wg21.link/p2474r1</a>
   <dt id="biblio-p2494r1">[P2494R1]
   <dd>Michał Dominiak. <a href="https://wg21.link/p2494r1"><cite>Relaxing range adaptors to allow for move only types</cite></a>. 17 January 2022. URL: <a href="https://wg21.link/p2494r1">https://wg21.link/p2494r1</a>
   <dt id="biblio-p2502r1">[P2502R1]
   <dd>Casey Carter. <a href="https://wg21.link/P2502R1"><cite>std::generator</cite></a>. 2022-01-25. URL: <a href="https://wg21.link/P2502R1">https://wg21.link/P2502R1</a>
   <dt id="biblio-p2508r1">[P2508R1]
   <dd>Barry Revzin. <a href="https://wg21.link/p2508r1"><cite>Exposing std::basic-format-string</cite></a>. 18 January 2022. URL: <a href="https://wg21.link/p2508r1">https://wg21.link/p2508r1</a>
   <dt id="biblio-p2529r0">[P2529R0]
   <dd>Mathias Stearn. <a href="https://wg21.link/P2529R0"><cite>generator should have T&amp;&amp; reference_type</cite></a>. 2022-01-25. URL: <a href="https://wg21.link/P2529R0">https://wg21.link/P2529R0</a>
   <dt id="biblio-p2532r0">[P2532R0]
   <dd>Eric Niebler. <a href="https://wg21.link/P2532R0"><cite>Removing exception_ptr from the Receiver Concept</cite></a>. 2022-02-01. URL: <a href="https://wg21.link/P2532R0">https://wg21.link/P2532R0</a>
  </dl>