<!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>P3054R0: 2023-12 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;
			border-bottom: 3px solid transparent;
			margin-bottom: -3px;
		}
		#toc .content:hover,
		#toc .content:focus {
			background: rgba(75%, 75%, 75%, .25);
			background: var(--a-hover-bg);
			border-bottom-color: #054572;
			border-bottom-color: var(--toclink-underline);
		}
		#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 82ce88815, updated Thu Sep 7 16:33:55 2023 -0700" name="generator">
  <link href="https://wg21.link/P3054" rel="canonical">
  <link href="https://isocpp.org/favicon.ico" rel="icon">
<style>/* Boilerplate: 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;
}

@media (prefers-color-scheme: dark) {
    :root {
        --selflink-text: black;
        --selflink-bg: silver;
        --selflink-hover-text: white;
    }
}
</style>
<style>/* Boilerplate: 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;
}

@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; }
}
</style>
<style>/* Boilerplate: 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>/* Boilerplate: style-issues */
a[href].issue-return {
    float: right;
    float: inline-end;
    color: var(--issueheading-text);
    font-weight: bold;
    text-decoration: none;
}
</style>
<style>/* Boilerplate: 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>/* Boilerplate: 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%;
}
.example > a.self-link,
.note > a.self-link,
.issue > a.self-link {
    /* These blocks are overflow:auto, so positioning outside
       doesn't work. */
    left: auto;
    right: 0;
}
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>
 <body class="h-entry">
  <div class="head">
   <p data-fill-with="logo"></p>
   <h1 class="p-name no-ref" id="title">P3054R0<br>2023-12 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="2024-01-13">2024-01-13</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:sinbal2l@gmail.com">Inbal Levi - Library Evolution Chair</a> (<span class="p-org org">MPGC Services LTD</span>)
     <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:fabio@fracassi.de">Fabio Fracassi - Library Evolution Assistant 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 Assistant Chair</a> (<span class="p-org org">Raven</span>)
     <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:billy.baker.cpp@gmail.com">Billy Baker - Library Evolution Incubator 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:nevin@cplusplusguy.com">Nevin Liber - Library Evolution Incubator Assistant Chair and Admin Chair</a> (<span class="p-org org">Argonne National Laboratory</span>)
     <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:corentin.jabot@gmail.com">Corentin Jabot - Library Mailing List Review Manager</a>
     <dt>Source:
     <dd><a href="https://github.com/inbal2l/wg21_library_evolution_polls_outcome_script/blob/main/2023_12_library_evolution_poll_outcomes.bs">GitHub</a>
     <dt>Project:
     <dd>ISO/IEC 14882 Programming Languages — C++, ISO/IEC JTC1/SC22/WG21
     <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="#poll-comments"><span class="secno">3</span> <span class="content">Selected Poll Comments</span></a>
     <ol class="toc">
      <li><a href="#poll-1-send-p0876r14-fiber_context---fibers-without-scheduler-to-library-working-group-for-c26"><span class="secno">3.1</span> <span class="content">Poll 1: Send "<span title="fiber_context - fibers without scheduler">[P0876R14]</span>: fiber_context - fibers without scheduler" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-2-send-p0447r26-introduction-of-stdhive-to-the-standard-library-to-library-working-group-for-c26"><span class="secno">3.2</span> <span class="content">Poll 2: Send "<span title="Introduction of std::hive to the standard library">[P0447R26]</span>: Introduction of std::hive to the standard library" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-3-send-p2542r7-viewsconcat-to-library-working-group-for-c26"><span class="secno">3.3</span> <span class="content">Poll 3: Send "<span title="views::concat">[P2542R7]</span>: views::concat" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-4-send-p2642r5-padded-mdspan-layouts-to-library-working-group-for-c26"><span class="secno">3.4</span> <span class="content">Poll 4: Send "<span title="Padded mdspan layouts">[P2642R5]</span>: Padded mdspan layouts" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-5-send-p2663r5-proposal-to-support-interleaved-complex-values-in-stdsimd-to-library-working-group-for-c26"><span class="secno">3.5</span> <span class="content">Poll 5: Send "<span title="Proposal to support interleaved complex values in std::simd">[P2663R5]</span>: Proposal to support interleaved complex values in std::simd" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-6-send-p2810r2-is_debugger_present-is_replaceable-to-library-working-group-for-c26"><span class="secno">3.6</span> <span class="content">Poll 6: Send "<span title="is_debugger_present is_replaceable">[P2810R2]</span>: is_debugger_present is_replaceable" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-7-send-p2809r2-trivial-infinite-loops-are-not-undefined-behavior-to-library-working-group-for-c26"><span class="secno">3.7</span> <span class="content">Poll 7: Send "<span title="Trivial infinite loops are not Undefined Behavior">[P2809R2]</span>: Trivial infinite loops are not Undefined Behavior" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-8-send-p2845r5-formatting-of-stdfilesystempath-to-library-working-group-for-c26"><span class="secno">3.8</span> <span class="content">Poll 8: Send "<span title="Formatting of std::filesystem::path">[P2845R5]</span>: Formatting of std::filesystem::path" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-9-send-p2862r1-text_encodingname-should-never-return-null-values-to-library-working-group-for-c26"><span class="secno">3.9</span> <span class="content">Poll 9: Send "<span title="text_encoding::name() should never return null values">[P2862R1]</span>: text_encoding::name() should never return null values" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-10-send-p2867r1-remove-deprecated-strstreams-from-c26-to-library-working-group-for-c26"><span class="secno">3.10</span> <span class="content">Poll 10: Send "<span title="Remove Deprecated strstreams From C++26">[P2867R1]</span>: Remove Deprecated strstreams From C++26" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-11-send-p2869r3-remove-deprecated-shared_ptr-atomic-access-apis-from-c26-to-library-working-group-for-c26"><span class="secno">3.11</span> <span class="content">Poll 11: Send "<span title="Remove Deprecated `shared_ptr` Atomic Access APIs From C++26">[P2869R3]</span>: Remove Deprecated shared_ptr Atomic Access APIs From C++26" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-12-send-p2866r1-remove-deprecated-volatile-features-from-c26-to-library-working-group-for-c26"><span class="secno">3.12</span> <span class="content">Poll 12: Send "<span title="Remove Deprecated Volatile Features From C++26">[P2866R1]</span>: Remove Deprecated Volatile Features From C++26" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-13-send-p2944r2-comparisons-for-reference_wrapper-to-library-working-group-for-c26"><span class="secno">3.13</span> <span class="content">Poll 13: Send "<span title="Comparisons for reference_wrapper">[P2944R2]</span>: Comparisons for reference_wrapper" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-14-send-p2933r1-extend-header-function-with-overloads-for-stdsimd-to-library-working-group-for-c26"><span class="secno">3.14</span> <span class="content">Poll 14: Send "<span title="std::simd overloads for <bit> header">[P2933R1]</span>: Extend <bit> header function with overloads for std::simd" to Library Working Group for C++26.</bit></span></a>
      <li><a href="#poll-15-send-p2976r0-freestanding-library-algorithm-numeric-and-random-to-library-working-group-for-c26"><span class="secno">3.15</span> <span class="content">Poll 15: Send "<span title="Freestanding Library: algorithm, numeric, and random">[P2976R0]</span>: Freestanding Library: algorithm, numeric, and random" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-16-send-p2968r2-make-stdignore-a-first-class-object-to-library-working-group-for-c26"><span class="secno">3.16</span> <span class="content">Poll 16: Send "<span title="Make std::ignore a first-class object">[P2968R2]</span>: Make std::ignore a first-class object" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-17-send-p2999r3-sender-algorithm-customization-to-library-working-group-for-c26"><span class="secno">3.17</span> <span class="content">Poll 17: Send "P2999R3: Sender Algorithm Customization" to Library Working Group for C++26.</span></a>
      <li><a href="#poll-18-approve-p2267r1-library-evolution-policies-and-create-sd-9-as-described"><span class="secno">3.18</span> <span class="content">Poll 18: Approve "<span title="Library Evolution Policies">[P2267R1]</span>: Library Evolution Policies" and create SD-9 as described.</span></a>
      <li><a href="#poll-19-approve-p2760r1-a-plan-for-c26-ranges"><span class="secno">3.19</span> <span class="content">Poll 19: Approve "<span title="A Plan for C++26 Ranges">[P2760R1]</span>: A Plan for C++26 Ranges".</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 2023-12, the C++ Library Evolution group conducted a series of electronic decision polls <a data-link-type="biblio" href="https://wg21.link/p3053r0" title="2023-12 Library Evolution Polls">[P3053R0]</a>.
This paper provides the results of those polls and summarizes the results.</p>
   <p>In total, 24 people participated in the polls.
Some participants opted to not vote on some polls (Poll 1, Poll 4, Poll 5, and Poll 17 had a low participation rate).
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>Poll 
      <th>SF 
      <th>WF 
      <th>N 
      <th>WA 
      <th>SA 
      <th>Outcome 
     <tr>
      <td> Poll 1: Send "<a data-link-type="biblio" href="https://wg21.link/p0876r14" title="fiber_context - fibers without scheduler">[P0876R14]</a>: fiber_context - fibers without scheduler" to Library Working Group for C++26. 
      <td>4 
      <td>7 
      <td>3 
      <td>1 
      <td>0 
      <td>Consensus in favor. 
     <tr>
      <td> Poll 2: Send "<a data-link-type="biblio" href="https://wg21.link/p0447r26" title="Introduction of std::hive to the standard library">[P0447R26]</a>: Introduction of std::hive to the standard library" to Library Working Group for C++26. 
      <td>8 
      <td>4 
      <td>3 
      <td>4 
      <td>2 
      <td>Weak consensus in favor. 
     <tr>
      <td> Poll 3: Send "<a data-link-type="biblio" href="https://wg21.link/p2542r7" title="views::concat">[P2542R7]</a>: views::concat" to Library Working Group for C++26. 
      <td>11 
      <td>8 
      <td>0 
      <td>0 
      <td>0 
      <td>Unanimous consensus in favor. 
     <tr>
      <td> Poll 4: Send "<a data-link-type="biblio" href="https://wg21.link/p2642r5" title="Padded mdspan layouts">[P2642R5]</a>: Padded mdspan layouts" to Library Working Group for C++26. 
      <td>7 
      <td>8 
      <td>1 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td> Poll 5: Send "<a data-link-type="biblio" href="https://wg21.link/p2663r5" title="Proposal to support interleaved complex values in std::simd">[P2663R5]</a>: Proposal to support interleaved complex values in std::simd" to Library Working Group for C++26. 
      <td>7 
      <td>4 
      <td>1 
      <td>1 
      <td>0 
      <td>Consensus in favor. 
     <tr>
      <td> Poll 6: Send "<a data-link-type="biblio" href="https://wg21.link/p2810r2" title="is_debugger_present is_replaceable">[P2810R2]</a>: is_debugger_present is_replaceable" to Library Working Group for C++26. 
      <td>9 
      <td>10 
      <td>2 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td> Poll 7: Send "<a data-link-type="biblio" href="https://wg21.link/p2809r2" title="Trivial infinite loops are not Undefined Behavior">[P2809R2]</a>: Trivial infinite loops are not Undefined Behavior" to Library Working Group for C++26. 
      <td>8 
      <td>11 
      <td>1 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td> Poll 8: Send "<a data-link-type="biblio" href="https://wg21.link/p2845r5" title="Formatting of std::filesystem::path">[P2845R5]</a>: Formatting of std::filesystem::path" to Library Working Group for C++26. 
      <td>8 
      <td>10 
      <td>0 
      <td>1 
      <td>0 
      <td>Consensus in favor. 
     <tr>
      <td> Poll 9: Send "<a data-link-type="biblio" href="https://wg21.link/p2862r1" title="text_encoding::name() should never return null values">[P2862R1]</a>: text_encoding::name() should never return null values" to Library Working Group for C++26. 
      <td>9 
      <td>10 
      <td>2 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td> Poll 10: Send "<a data-link-type="biblio" href="https://wg21.link/p2867r1" title="Remove Deprecated strstreams From C++26">[P2867R1]</a>: Remove Deprecated strstreams From C++26" to Library Working Group for C++26. 
      <td>19 
      <td>4 
      <td>0 
      <td>0 
      <td>0 
      <td>Unanimous consensus in favor. 
     <tr>
      <td> Poll 11: Send "<a data-link-type="biblio" href="https://wg21.link/p2869r3" title="Remove Deprecated `shared_ptr` Atomic Access APIs From C++26">[P2869R3]</a>: Remove Deprecated shared_ptr Atomic Access APIs From C++26" to Library Working Group for C++26. 
      <td>12 
      <td>7 
      <td>0 
      <td>0 
      <td>0 
      <td>Unanimous consensus in favor. 
     <tr>
      <td> Poll 12: Send "<a data-link-type="biblio" href="https://wg21.link/p2866r1" title="Remove Deprecated Volatile Features From C++26">[P2866R1]</a>: Remove Deprecated Volatile Features From C++26" to Library Working Group for C++26. 
      <td>12 
      <td>6 
      <td>3 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td> Poll 13: Send "<a data-link-type="biblio" href="https://wg21.link/p2944r2" title="Comparisons for reference_wrapper">[P2944R2]</a>: Comparisons for reference_wrapper" to Library Working Group for C++26. 
      <td>11 
      <td>10 
      <td>0 
      <td>1 
      <td>0 
      <td>Consensus in favor. 
     <tr>
      <td>
        Poll 14: Send "<a data-link-type="biblio" href="https://wg21.link/p2933r1" title="std::simd overloads for <bit> header">[P2933R1]</a>: Extend 
       <bit> header function with overloads for std::simd" to Library Working Group for C++26. </bit>
      <td>9 
      <td>7 
      <td>0 
      <td>1 
      <td>0 
      <td>Consensus in favor. 
     <tr>
      <td> Poll 15: Send "<a data-link-type="biblio" href="https://wg21.link/p2976r0" title="Freestanding Library: algorithm, numeric, and random">[P2976R0]</a>: Freestanding Library: algorithm, numeric, and random" to Library Working Group for C++26. 
      <td>13 
      <td>6 
      <td>1 
      <td>0 
      <td>1 
      <td>Consensus in favor. 
     <tr>
      <td> Poll 16: Send "<a data-link-type="biblio" href="https://wg21.link/p2968r2" title="Make std::ignore a first-class object">[P2968R2]</a>: Make std::ignore a first-class object" to Library Working Group for C++26. 
      <td>10 
      <td>6 
      <td>3 
      <td>2 
      <td>0 
      <td>Consensus in favor. 
     <tr>
      <td> Poll 17: Send "<a data-link-type="biblio" href="https://wg21.link/p2999r3" title="Sender Algorithm Customization">[P2999R3]</a>: Sender Algorithm Customization" to Library Working Group for C++26. 
      <td>7 
      <td>6 
      <td>1 
      <td>0 
      <td>1 
      <td>Consensus in favor. 
     <tr>
      <td> Poll 18: Approve "<a data-link-type="biblio" href="https://wg21.link/p2267r1" title="Library Evolution Policies">[P2267R1]</a>: Library Evolution Policies" and create SD-9 as described. 
      <td>10 
      <td>6 
      <td>3 
      <td>1 
      <td>0 
      <td>Consensus in favor. 
     <tr>
      <td> Poll 19: Approve "<a data-link-type="biblio" href="https://wg21.link/p2760r1" title="A Plan for C++26 Ranges">[P2760R1]</a>: A Plan for C++26 Ranges". 
      <td>10 
      <td>7 
      <td>2 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
   </table>
   <p>All the polls have consensus in favor, and will be forwarded to LWG.</p>
   <h2 class="heading settled" data-level="3" id="poll-comments"><span class="secno">3. </span><span class="content">Selected Poll Comments</span><a class="self-link" href="#poll-comments"></a></h2>
   <p>For some of the comments, small parts were removed to anonymize.</p>
   <h3 class="heading settled" data-level="3.1" id="poll-1-send-p0876r14-fiber_context---fibers-without-scheduler-to-library-working-group-for-c26"><span class="secno">3.1. </span><span class="content">Poll 1: Send "<a data-link-type="biblio" href="https://wg21.link/p0876r14" title="fiber_context - fibers without scheduler">[P0876R14]</a>: fiber_context - fibers without scheduler" to Library Working Group for C++26.</span><a class="self-link" href="#poll-1-send-p0876r14-fiber_context---fibers-without-scheduler-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>This is a good example of a facility that belongs in the Standard Library: it cannot be implemented in standard c++, and the existence of boost.context is proof there is demand.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Fibers are an important counterpart to coroutines for writing high-concurrency systems on limited sets of OS threads</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I hope it’s possible to implement this for all platforms, not just the ones that the authors have access to when developing Boost.Context.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>There is very little motivation in the paper as to why this is something the standard needs.
Sure it’s hard to implement in library, but it’s done, and i doubt boost.fiber will stop depending on boost.context for the foreseeable future.
Given the lack of library support for coroutines in the standard, the fact that P2300 is still making its way through the standard and that this proposal is utterly useless without a lot of higher level constructs, I am not sure this is the right time for this proposal.
Speaking of usefulness over time, there is active work and research into kernel support for lightweight thread, which _might_ negate most of the motivation for this proposal over the next few years.
The back on forth on cancellation over the last few revisions is a bit concerning, that being said this is not a user-facility and it looks usable as an implementation detail of a fiber library satisfying the requirements of P2300, so maybe it’s fine.</p>
    <p>Ultimately, I haven’t been involved enough in the discussion to vote strongly, hence neutral.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>We don’t have a particular need for this, but I can see how it positively impacts other codebases and will enable authorship of portable fiber-using code.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>It’s not clear to me that this new abstraction is better enough than std::thread, std::jthread, coroutines, sender/receiver, or third-party libraries to justify expanding the standard library.
The word "experience" (as in "implementation experience" or "usage experience") does not appear in the proposal.
Looks like the prior art is Boost.Context (2014), but much has changed since 2014 and the proposed wording doesn’t closely match Boost.Context anymore.
Could the author persuade Boost.Context to adopt the R14 API? If not, why not?</p>
    <p>— Weakly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.2" id="poll-2-send-p0447r26-introduction-of-stdhive-to-the-standard-library-to-library-working-group-for-c26"><span class="secno">3.2. </span><span class="content">Poll 2: Send "<a data-link-type="biblio" href="https://wg21.link/p0447r26" title="Introduction of std::hive to the standard library">[P0447R26]</a>: Introduction of std::hive to the standard library" to Library Working Group for C++26.</span><a class="self-link" href="#poll-2-send-p0447r26-introduction-of-stdhive-to-the-standard-library-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>This proposal has been a harder sell than it should have been, due to the fact that users of such containers do not go «the open source way» with their code which obscures (to some) the usefulness of this data structure. Many of our users will appreciate this.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a useful container for programs that need stable references, which is common in many scenarios. Even though third party solutions might be better suited for maximum performance having it in the standard will help to create a common interface/vocabulary</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is useful, none of the various objections over the years have enough merit to prevent this being added to the standard.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>
     After a long discussion, I’m convinced that this can be a good addition to the standard lib, for some domains (and as it’s "isolated" within a "
     <hive>" header, I don’t have concerns about the impact on the rest of the community).</hive>
    </p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Several engineers in the gaming domain see benefits to this library getting more exposure by being standardized. I’m not opposed to this given the popularity of the library and the diversity of those calling for its standardization.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>The wording is in a good state, but I’m not sold on this facility being a great fit for the standard library.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>Don’t feel that it belongs to C++ standard library. It seems very specific container for the specific use-case. On the other hand, if people think it’s necessary and see its value I don’t want to create a huge obstacle for that.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p><code class="highlight"><c- n>hive</c-></code> is a good container, but it does not belong in the standard library. Adding to the standard library is expensive, using precious committee and implementer effort. Changing things in the standard is hard, so mistakes are expensive to fix, and standard facilities cannot always be updated to reflect the latest practices. Standardizing <code class="highlight"><c- n>hive</c-></code> would be unwise.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <blockquote>
    <p>I still cannot see a compelling motivation for why this need to lives in the STL rather than a library.
I do not believe standardization will lead to robust and efficient implementations of the feature over time. We are bound by ABI stabilities.
Vector is best, use a package manager when you choose from the rest.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.3" id="poll-3-send-p2542r7-viewsconcat-to-library-working-group-for-c26"><span class="secno">3.3. </span><span class="content">Poll 3: Send "<a data-link-type="biblio" href="https://wg21.link/p2542r7" title="views::concat">[P2542R7]</a>: views::concat" to Library Working Group for C++26.</span><a class="self-link" href="#poll-3-send-p2542r7-viewsconcat-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>We have our own concat() that this could replace.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I look forward to this feature as a way to present all kinds of noncontiguous data structures as a single range.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I think it’s a little surprising we don’t already have this!</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This helps complete the ranges library and has some motivating examples.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.4" id="poll-4-send-p2642r5-padded-mdspan-layouts-to-library-working-group-for-c26"><span class="secno">3.4. </span><span class="content">Poll 4: Send "<a data-link-type="biblio" href="https://wg21.link/p2642r5" title="Padded mdspan layouts">[P2642R5]</a>: Padded mdspan layouts" to Library Working Group for C++26.</span><a class="self-link" href="#poll-4-send-p2642r5-padded-mdspan-layouts-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>This feature lets users express two common cases in one, both of which are important to optimize:</p>
    <ol>
     <li data-md>
      <p>overalignment (e.g., for SIMD), and</p>
     <li data-md>
      <p>the contiguous access that results from many cases of taking <code class="highlight"><c- n>submdspan</c-></code> of a <code class="highlight"><c- n>layout_left</c-></code> or <code class="highlight"><c- n>layout_right</c-></code> <code class="highlight"><c- n>mdspan</c-></code>.</p>
    </ol>
    <p>Regarding Case (2), the proposed layouts exactly describe what the Fortran and C BLAS Standard interface accepts for rank-2 arrays.
The main purpose of these layouts is not for the compiler to optimize, but for users to declare that their data have properties that permit optimization.  For example, this would permit algorithm specializations that call into optimized C or Fortran libraries.
The papers considers design alternatives, such as a strided layout that would permit encoding any combination of strides at compile time. That layout would be more generally useful, but most users would not need its full generality.  When I worry about whether the previous sentence is accurate, I tell myself that LEWG was paying attention to that part of the paper and made an informed decision.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>A must-have when programming dense matrices.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Even though it increases the complexity of <code class="highlight"><c- n>mdspan</c-></code>, I’m convinced that this is useful for some users, and as we have defaults, I don’t think it creates a burden.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>These are needed in many common applications for mdspan. While it adds some complexity into the mdspan, it will ultimately reduce the complexity for end users, because they will be able to write their application code uniformly and have it behave optimally in various environments or contexts.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I worry about our span library getting overcomplicated, but I recognize the need for this although my organization doesn’t have it.</p>
    <p>— Neutral</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.5" id="poll-5-send-p2663r5-proposal-to-support-interleaved-complex-values-in-stdsimd-to-library-working-group-for-c26"><span class="secno">3.5. </span><span class="content">Poll 5: Send "<a data-link-type="biblio" href="https://wg21.link/p2663r5" title="Proposal to support interleaved complex values in std::simd">[P2663R5]</a>: Proposal to support interleaved complex values in std::simd" to Library Working Group for C++26.</span><a class="self-link" href="#poll-5-send-p2663r5-proposal-to-support-interleaved-complex-values-in-stdsimd-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>Interleaved real/imaginary is the norm for many data structures, so we ought to support it</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Industrial-proof practice.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’m not opposed although my organization doesn’t have a need for this.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>While the paper and language itself are fine, the FP16 technology mentioned is only 1 year old. This limits both user experience and feedback. It might be better to wait a few years to guarantee that this instruction set will not be amended/up-versioned, before settling on an API. It is also only available in high-end CPUs (for Intel), which means it will not be used in gaming, where it would be of some benefit. As such this paper seems to serve a fraction of a fraction of users.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.6" id="poll-6-send-p2810r2-is_debugger_present-is_replaceable-to-library-working-group-for-c26"><span class="secno">3.6. </span><span class="content">Poll 6: Send "<a data-link-type="biblio" href="https://wg21.link/p2810r2" title="is_debugger_present is_replaceable">[P2810R2]</a>: is_debugger_present is_replaceable" to Library Working Group for C++26.</span><a class="self-link" href="#poll-6-send-p2810r2-is_debugger_present-is_replaceable-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>Widely useful and widely implemented.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’m not a big fan of the std:: debugger functions (they seem like unpleasant to use for beginners compared with existing vendor-provided facilities) but given that we’ll get them, this feature should be part of the set.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>While I debate the specific need for the original functionality there is no doubt that this would an improvement on it.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I don’t need that feature, but people might want to have it.</p>
    <p>— Neutral</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.7" id="poll-7-send-p2809r2-trivial-infinite-loops-are-not-undefined-behavior-to-library-working-group-for-c26"><span class="secno">3.7. </span><span class="content">Poll 7: Send "<a data-link-type="biblio" href="https://wg21.link/p2809r2" title="Trivial infinite loops are not Undefined Behavior">[P2809R2]</a>: Trivial infinite loops are not Undefined Behavior" to Library Working Group for C++26.</span><a class="self-link" href="#poll-7-send-p2809r2-trivial-infinite-loops-are-not-undefined-behavior-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>I support that which weakens the division between C and C++, within reason, and this seems a solid case for where C++ is not quite in the right.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>trivial infinite loops are common used in daemon’s and business rules engines.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Less trivial UB is better, especially when the programmer’s intent is clear.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This makes C++ more consistent with C, and blesses a common idiom in low-level code, without losing the forward progress guarantees that C++ needs to reason about threads.
We appreciate how the author conservatively started with matching the C semantics (in R0), then incorporated feedback to develop a more refined model.
I don’t really like that the specific syntactic form of the loop affects behavior.  I’d rather that users had to opt in to a special library function or language construct in order to write an infinite loop.  On the other hand, the author’s approach blesses common practice and consistency with C.  We should favor those two things without strong reasons against.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>yield_forever is an okay-ish name.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.8" id="poll-8-send-p2845r5-formatting-of-stdfilesystempath-to-library-working-group-for-c26"><span class="secno">3.8. </span><span class="content">Poll 8: Send "<a data-link-type="biblio" href="https://wg21.link/p2845r5" title="Formatting of std::filesystem::path">[P2845R5]</a>: Formatting of std::filesystem::path" to Library Working Group for C++26.</span><a class="self-link" href="#poll-8-send-p2845r5-formatting-of-stdfilesystempath-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>Being able to format paths is very useful and this paper adds support for this leveraging existing solutions such as escaping and Unicode support in std::format.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This should improve diagnostics.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This functionality will get use in my organization and I expect users in general to make use of this.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.9" id="poll-9-send-p2862r1-text_encodingname-should-never-return-null-values-to-library-working-group-for-c26"><span class="secno">3.9. </span><span class="content">Poll 9: Send "<a data-link-type="biblio" href="https://wg21.link/p2862r1" title="text_encoding::name() should never return null values">[P2862R1]</a>: text_encoding::name() should never return null values" to Library Working Group for C++26.</span><a class="self-link" href="#poll-9-send-p2862r1-text_encodingname-should-never-return-null-values-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>This improves compatibility with C and makes the interface more consistent.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The billion dollar mistake in other languages is only the hundred dollar feature in C++. Please let’s not increase this cost.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This change ,akes it easier to work with the text_encoding API.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>nullptr checks make client code convoluted</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I can honestly see value to both the existing and proposed return values.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>This is a bug fix to a rarely used facility. I’m not opposed.</p>
    <p>— Neutral</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.10" id="poll-10-send-p2867r1-remove-deprecated-strstreams-from-c26-to-library-working-group-for-c26"><span class="secno">3.10. </span><span class="content">Poll 10: Send "<a data-link-type="biblio" href="https://wg21.link/p2867r1" title="Remove Deprecated strstreams From C++26">[P2867R1]</a>: Remove Deprecated strstreams From C++26" to Library Working Group for C++26.</span><a class="self-link" href="#poll-10-send-p2867r1-remove-deprecated-strstreams-from-c26-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>After decades of depreciation, we finally have all replacements in the standard library where strstream could have claimed to provide superior performance. It no longer has.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>strstream are a terribly broken API, there are much better facilities for this, even in iostreams.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Removing unsafe cruft in iostream is always welcomed</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>These have been superseded now, at last.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.11" id="poll-11-send-p2869r3-remove-deprecated-shared_ptr-atomic-access-apis-from-c26-to-library-working-group-for-c26"><span class="secno">3.11. </span><span class="content">Poll 11: Send "<a data-link-type="biblio" href="https://wg21.link/p2869r3" title="Remove Deprecated `shared_ptr` Atomic Access APIs From C++26">[P2869R3]</a>: Remove Deprecated shared_ptr Atomic Access APIs From C++26" to Library Working Group for C++26.</span><a class="self-link" href="#poll-11-send-p2869r3-remove-deprecated-shared_ptr-atomic-access-apis-from-c26-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>These should be removed since they are bug-prone.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>If used, will be used wrongly, therefor I’m happy to remove deprecated features and do cleanups.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The API is not in itself problematic, but there are better ways to express things, and we should encourage them.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>
     The rationale in the paper is completely bogus. These APIs have no silent UB trap, that’s based on a misunderstanding and has no justification in the standard. But I do agree that atomic
     <shared_ptrU0003Ct>> is better, so we should push people to that.</shared_ptrU0003Ct>
    </p>
    <p>— Weakly Favor</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.12" id="poll-12-send-p2866r1-remove-deprecated-volatile-features-from-c26-to-library-working-group-for-c26"><span class="secno">3.12. </span><span class="content">Poll 12: Send "<a data-link-type="biblio" href="https://wg21.link/p2866r1" title="Remove Deprecated Volatile Features From C++26">[P2866R1]</a>: Remove Deprecated Volatile Features From C++26" to Library Working Group for C++26.</span><a class="self-link" href="#poll-12-send-p2866r1-remove-deprecated-volatile-features-from-c26-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>I was scared this one would go too far, but reading the details I think it’s fine and reasonable.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>volatile should only be used where special memory is used.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’m skeptical of the language changes there, e.g. changing decltype(vi=42) from volatile int&amp; to void so that <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>assignable_from</c-><c- o>&lt;</c-><c- k>volatile</c-> <c- b>int</c-><c- o>&amp;</c-><c- p>,</c-> <c- b>int</c-><c- o>></c-></code> will now be false not true. But that’s not an LEWG concern.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Happy to remove deprecated features and do cleanups, especially if the behaviour is not as expected</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>It sounds like there are some questions remaining, at least in Mattermost discussion on the SG01 channel.  The concern is behavior of interprocess communication via atomics.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>It was hard to follow the series of deprecations/undeprecations to understand where volatile was in fact being preserved. A single table for all removed/non-removed areas of it’s use would be strongly appreciated.</p>
    <p>— Neutral</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.13" id="poll-13-send-p2944r2-comparisons-for-reference_wrapper-to-library-working-group-for-c26"><span class="secno">3.13. </span><span class="content">Poll 13: Send "<a data-link-type="biblio" href="https://wg21.link/p2944r2" title="Comparisons for reference_wrapper">[P2944R2]</a>: Comparisons for reference_wrapper" to Library Working Group for C++26.</span><a class="self-link" href="#poll-13-send-p2944r2-comparisons-for-reference_wrapper-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>
     reference_wrapper
     <t> should be as close to a T&amp; as possible, and the current inconsistencies are annoying.</t>
    </p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This proposal makes <code class="highlight"><c- n>reference_wrapper</c-></code> behave more consistently and usefully.</p>
    <p>The set of users who use types whose <code class="highlight"><c- k>operator</c-><c- o>==</c-></code> returns non-<code class="highlight"><c- b>bool</c-></code> (e.g., <code class="highlight"><c- n>valarray</c-></code>, or simd types) probably does not intersect much with the set of users who use <code class="highlight"><c- n>reference_wrapper</c-></code> at all.
Those in that small intersection almost certainly do not find themselves using <code class="highlight"><c- n>reference_wrapper</c-></code> with those types.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>As we don’t block the ability to support non-trivial types, I’m happy to support this modification.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>bool op==, rather than auto op==, seems petty when the cost of specifying auto op== is so low.
It doesn’t even accomplish the desired goal since other conversions allow op== to (sometimes) work.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.14" id="poll-14-send-p2933r1-extend-header-function-with-overloads-for-stdsimd-to-library-working-group-for-c26"><span class="secno">3.14. </span><span class="content">Poll 14: Send "<a data-link-type="biblio" href="https://wg21.link/p2933r1" title="std::simd overloads for <bit> header">[P2933R1]</a>: Extend <bit> header function with overloads for std::simd" to Library Working Group for C++26.</bit></span><a class="self-link" href="#poll-14-send-p2933r1-extend-header-function-with-overloads-for-stdsimd-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>
     A straightforward paper that does everything consistently with a 
     <bit> header where applicable.</bit>
    </p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Get the most out of your hardware.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This helps fill out SIMD functionality.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This extension seems like a valid use case that we should support in SIMD, to fit to what users expect</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.15" id="poll-15-send-p2976r0-freestanding-library-algorithm-numeric-and-random-to-library-working-group-for-c26"><span class="secno">3.15. </span><span class="content">Poll 15: Send "<a data-link-type="biblio" href="https://wg21.link/p2976r0" title="Freestanding Library: algorithm, numeric, and random">[P2976R0]</a>: Freestanding Library: algorithm, numeric, and random" to Library Working Group for C++26.</span><a class="self-link" href="#poll-15-send-p2976r0-freestanding-library-algorithm-numeric-and-random-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>This makes (big parts of) the Library more portable / usable in more contexts.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>No objections to that, keeping in mind that parallel algorithms are covered.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Freestanding abilities should be applied equally.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I remain unconvinced that investment in freestanding is worthwhile.
a) libc++ doesn’t support it,
b) libstdc++'s freestanding is rarely used,
c) libstdc++ makes its own decisions as to what is in free standing and is happy to ignore what we specify, and
d) embedded processors have their own standard libraries (e.g. avr-libstdcpp) that include parts of the standard that their devices support (like chono).</p>
    <p>If we want to support these use cases, we should find out what they need and support them instead of busying ourselves with work without impact.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.16" id="poll-16-send-p2968r2-make-stdignore-a-first-class-object-to-library-working-group-for-c26"><span class="secno">3.16. </span><span class="content">Poll 16: Send "<a data-link-type="biblio" href="https://wg21.link/p2968r2" title="Make std::ignore a first-class object">[P2968R2]</a>: Make std::ignore a first-class object" to Library Working Group for C++26.</span><a class="self-link" href="#poll-16-send-p2968r2-make-stdignore-a-first-class-object-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>This makes the existing spec more precise, which would be enough improvement already. Making it usable in more contexts is a nice benefit.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is vocabulary that helps developers to express their intent more clearly.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I prefer the (void) cast, myself, but I can understand the teachability and self-documenting code arguments.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I disagree with the motivation of this proposal, but I otherwise don’t have an objection with the specification change.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>Teach the void cast. Or <span>[maybe_unused]</span>. Dragging the stdlib into this seems unnecessary.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>
     I don’t agree with the author that the style of syntax proposed makes for simple, unambiguous semantics.
In fact, it looks incredibly confusing to newcomers, to whom std::ignore is an object which doesn’t take on any value, and then you’re assigning a function to it, which should have no effect, but it does have some effect?
std::ignore "An object of unspecified type such that any value can be assigned to it with no effect."
Sorry, this is just bad karma. Just change standard practice to use static_cast
     <void>. Done.</void>
    </p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>I would really hate people start to use that style of programming in earnest, and I certainly hope this is not recommend by standards...
but apparently that ship has sailed?</p>
    <p>— Weakly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.17" id="poll-17-send-p2999r3-sender-algorithm-customization-to-library-working-group-for-c26"><span class="secno">3.17. </span><span class="content">Poll 17: Send "P2999R3: Sender Algorithm Customization" to Library Working Group for C++26.</span><a class="self-link" href="#poll-17-send-p2999r3-sender-algorithm-customization-to-library-working-group-for-c26"></a></h3>
   <blockquote>
    <p>This improves the interface and removes excessive use of tag_invoke.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a critical fix for senders. Without it, customization is completely broken, especially for <code class="highlight"><c- n>on</c-></code> and <code class="highlight"><c- n>transfer</c-></code>.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is an important facility that enables users to archive portable good to optimal performance in diverse concurrency contexts.
While it adds some complexity into the S/R machinery it will ultimately reduce complexity for end user of S/R, because they won’t have to search for and implement complicated workarounds for the missing customizations.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>It’s definitely better to have a lazy customization because senders/receivers adaptors should do the right thing base on the execution context they belong to (that is represented by scheduler).</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>It seems good, but this proposal is very complex and I have not been part of the team that spent significant time reviewing it so taking a strong stance would be irresponsible.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Do we have sender, yet? A bit like putting the cart before the horse.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This library is overly complex and this proposal makes it even more so.
I’m unconvinced that "domains" is a well-defined abstraction, structured bindings should be used as a primary API interface for decomposition, and that there is a need for both bottom-up and top-down optimization.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.18" id="poll-18-approve-p2267r1-library-evolution-policies-and-create-sd-9-as-described"><span class="secno">3.18. </span><span class="content">Poll 18: Approve "<a data-link-type="biblio" href="https://wg21.link/p2267r1" title="Library Evolution Policies">[P2267R1]</a>: Library Evolution Policies" and create SD-9 as described.</span><a class="self-link" href="#poll-18-approve-p2267r1-library-evolution-policies-and-create-sd-9-as-described"></a></h3>
   <blockquote>
    <p>I strongly support this effort. Too many authors have been subjected to changing whims of our working groups (due to changing memberships of our worling groups), at least in the last decade.
The table at the very end seems confusing to me but the rest of the paper’s worthwhile, and matches what I’ve been advocating in LEWG (when I was there) since 2016.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>A set of policies should reduce time spent reviewing proposals that conform to policies.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>We desperately need policies, and this is step 0 for achieving that.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Creating policies as a way to improve committee efficiency is a worthwhile experiment although it remains to be seen if it will succeed.
I think the "process of setting a policy" should not be different from adopting any other paper though. I, in particular, dislike the idea of the "one month before adoption" hard rule. Consensus should be sufficient.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a good start to codifying Library Evolution practices. Constant work and culture change will be needed to make this effort successful.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I think the following requirement: "A survey of the status quo for this topic, in the wider C++ community. Preferably, this should contain the impact on different domains and industries." may be a lot harder to achieve than is expected - though it would doubtless be necessary sometimes.
You may want to soften it to "wider C++ community where necessary or the whole of LEWG where it is not".</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Sorry, I was not part of the discussion but I carefully read the paper, thus let me explain my Neutral.</p>
    <p>Although I pretty much agree with the direction of the paper I don’t feel that all the pros of establishing policies listed in the paper really work in practice.
First of all, 5.2 says "A policy is any technical rule or technical guideline...", which to me is contradictory. I think the policy (as it is stated in the paper) is much closer to the rule rather than to a guideline because there is a quite formal process behind. The guideline is softer than a rule (at least, in my head). I understand that it’s hard to imagine applying even a guideline without a written paper but still as P2267 says it will be time consuming to introduce a policy and reconsider it in the future if necessary.
The real value from policy that I see is "Policies make the standardization process friendly for newcomers". That is 100% true because it allows the newcomers to prepare a more solid proposal from the very beginning, assuming the policy also has a rationale coupled with it. In that case it does save C++ standard committee time.
"Policies save time for both authors and the committee" is questionable to me if going beyond a newcomers' case. We previously had the experience when we spent time to introduce a policy and then spent time to cancel it. Doing that also creates the inconsistency in C++ standard library, which makes "Policies create uniformity in users’ expectations from the behavior of different parts of the standard library" pro questionable as well.
What I would like to see is a list of "common practices" or "guidelines", which give everybody (no matter if the attendee is a newcomer or not) a common way of thinking. Of course, guidelines should also be reviewed and provided with a rationale. And I do agree that if the authors on a new proposal do not apply the guideline it should be explained in this new proposal.
The key difference for me between policies and guidelines is the latter are softer and potentially could create less overhead if we are able to find the right balance and establish the right process.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>Sounds like bureaucratic capture. I’m leery of the proposed rule "In order to schedule a meeting for re-discussing a policy, there should be new information." What if a policy is made that’s bad?</p>
    <p>— Weakly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.19" id="poll-19-approve-p2760r1-a-plan-for-c26-ranges"><span class="secno">3.19. </span><span class="content">Poll 19: Approve "<a data-link-type="biblio" href="https://wg21.link/p2760r1" title="A Plan for C++26 Ranges">[P2760R1]</a>: A Plan for C++26 Ranges".</span><a class="self-link" href="#poll-19-approve-p2760r1-a-plan-for-c26-ranges"></a></h3>
   <blockquote>
    <p>Strongly in Favor assuming that authors will add parallel algorithms with ranges as was discussed in both SG9 and LEWG.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>It’s good for LEWG to have a public, agreed-upon plan for Ranges development. The table in Section 3 offers encouragement -- it shows many range-v3 features already in C++23, and others in progress.
The paper helpfully points out some challenges with defining new features like <code class="highlight"><c- n>cache_last</c-></code>. I generally agree with the prioritization (Tiers 1, 2, and 3).</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>It seems reasonable, but ranges are not an easily approachable part of our library these days and it’s difficult to forge a strong opinion on these features without spending a _lot_ of time on them.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Plan seems reasonable. I do hope that things come up that _aren’t_ in the plan though, like a reasonable output range abstraction that doesn’t have trivial buffer overflow footguns.</p>
    <p>— Weakly Favor</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-p0447r26">[P0447R26]
   <dd>Matt Bentley. <a href="https://wg21.link/p0447r26"><cite>Introduction of std::hive to the standard library</cite></a>. 17 December 2023. URL: <a href="https://wg21.link/p0447r26">https://wg21.link/p0447r26</a>
   <dt id="biblio-p0876r14">[P0876R14]
   <dd>Oliver Kowalke, Nat Goodspeed. <a href="https://wg21.link/p0876r14"><cite>fiber_context - fibers without scheduler</cite></a>. 13 October 2023. URL: <a href="https://wg21.link/p0876r14">https://wg21.link/p0876r14</a>
   <dt id="biblio-p2267r1">[P2267R1]
   <dd>Inbal Levi, Ben Craig, Fabio Fracassi. <a href="https://wg21.link/p2267r1"><cite>Library Evolution Policies</cite></a>. 23 November 2023. URL: <a href="https://wg21.link/p2267r1">https://wg21.link/p2267r1</a>
   <dt id="biblio-p2542r7">[P2542R7]
   <dd>Hui Xie, S. Levent Yilmaz. <a href="https://wg21.link/p2542r7"><cite>views::concat</cite></a>. 2 December 2023. URL: <a href="https://wg21.link/p2542r7">https://wg21.link/p2542r7</a>
   <dt id="biblio-p2642r5">[P2642R5]
   <dd>Christian Trott, Mark Hoemmen,Damien Lebrun-Grandie,Nicolas Morales,Malte Förster,Jiaming Yuan. <a href="https://wg21.link/p2642r5"><cite>Padded mdspan layouts</cite></a>. 5 December 2023. URL: <a href="https://wg21.link/p2642r5">https://wg21.link/p2642r5</a>
   <dt id="biblio-p2663r5">[P2663R5]
   <dd>Daniel Towner, Ruslan Arutyunyan. <a href="https://wg21.link/p2663r5"><cite>Proposal to support interleaved complex values in std::simd</cite></a>. 8 December 2023. URL: <a href="https://wg21.link/p2663r5">https://wg21.link/p2663r5</a>
   <dt id="biblio-p2760r1">[P2760R1]
   <dd>Barry Revzin. <a href="https://wg21.link/p2760r1"><cite>A Plan for C++26 Ranges</cite></a>. 15 December 2023. URL: <a href="https://wg21.link/p2760r1">https://wg21.link/p2760r1</a>
   <dt id="biblio-p2809r2">[P2809R2]
   <dd>JF Bastien. <a href="https://wg21.link/p2809r2"><cite>Trivial infinite loops are not Undefined Behavior</cite></a>. 14 October 2023. URL: <a href="https://wg21.link/p2809r2">https://wg21.link/p2809r2</a>
   <dt id="biblio-p2810r2">[P2810R2]
   <dd>René Ferdinand Rivera Morell, Ben Craig. <a href="https://wg21.link/p2810r2"><cite>is_debugger_present is_replaceable</cite></a>. 3 December 2023. URL: <a href="https://wg21.link/p2810r2">https://wg21.link/p2810r2</a>
   <dt id="biblio-p2845r5">[P2845R5]
   <dd>Victor Zverovich. <a href="https://wg21.link/p2845r5"><cite>Formatting of std::filesystem::path</cite></a>. 24 November 2023. URL: <a href="https://wg21.link/p2845r5">https://wg21.link/p2845r5</a>
   <dt id="biblio-p2862r1">[P2862R1]
   <dd>Daniel Krügler. <a href="https://wg21.link/p2862r1"><cite>text_encoding::name() should never return null values</cite></a>. 24 September 2023. URL: <a href="https://wg21.link/p2862r1">https://wg21.link/p2862r1</a>
   <dt id="biblio-p2866r1">[P2866R1]
   <dd>Alisdair Meredith. <a href="https://wg21.link/p2866r1"><cite>Remove Deprecated Volatile Features From C++26</cite></a>. 16 September 2023. URL: <a href="https://wg21.link/p2866r1">https://wg21.link/p2866r1</a>
   <dt id="biblio-p2867r1">[P2867R1]
   <dd>Alisdair Meredith. <a href="https://wg21.link/p2867r1"><cite>Remove Deprecated strstreams From C++26</cite></a>. 16 September 2023. URL: <a href="https://wg21.link/p2867r1">https://wg21.link/p2867r1</a>
   <dt id="biblio-p2869r3">[P2869R3]
   <dd>Alisdair Meredith. <a href="https://wg21.link/p2869r3"><cite>Remove Deprecated `shared_ptr` Atomic Access APIs From C++26</cite></a>. 3 December 2023. URL: <a href="https://wg21.link/p2869r3">https://wg21.link/p2869r3</a>
   <dt id="biblio-p2933r1">[P2933R1]
   <dd>Daniel Towner, Ruslan Arutyunyan. <a href="https://wg21.link/p2933r1"><cite>std::simd overloads for &lt;bit> header</cite></a>. 8 December 2023. URL: <a href="https://wg21.link/p2933r1">https://wg21.link/p2933r1</a>
   <dt id="biblio-p2944r2">[P2944R2]
   <dd>Barry Revzin. <a href="https://wg21.link/p2944r2"><cite>Comparisons for reference_wrapper</cite></a>. 17 September 2023. URL: <a href="https://wg21.link/p2944r2">https://wg21.link/p2944r2</a>
   <dt id="biblio-p2968r2">[P2968R2]
   <dd>Peter Sommerlad. <a href="https://wg21.link/p2968r2"><cite>Make std::ignore a first-class object</cite></a>. 13 December 2023. URL: <a href="https://wg21.link/p2968r2">https://wg21.link/p2968r2</a>
   <dt id="biblio-p2976r0">[P2976R0]
   <dd>Ben Craig. <a href="https://wg21.link/p2976r0"><cite>Freestanding Library: algorithm, numeric, and random</cite></a>. 17 September 2023. URL: <a href="https://wg21.link/p2976r0">https://wg21.link/p2976r0</a>
   <dt id="biblio-p2999r3">[P2999R3]
   <dd>Eric Niebler. <a href="https://wg21.link/p2999r3"><cite>Sender Algorithm Customization</cite></a>. 13 December 2023. URL: <a href="https://wg21.link/p2999r3">https://wg21.link/p2999r3</a>
   <dt id="biblio-p3053r0">[P3053R0]
   <dd>Inbal Levi, Fabio Fracassi, Ben Craig, Nevin Liber, Billy Baker, Corentin Jabot. <a href="https://wg21.link/p3053r0"><cite>2023-12 Library Evolution Polls</cite></a>. 15 December 2023. URL: <a href="https://wg21.link/p3053r0">https://wg21.link/p3053r0</a>
  </dl>