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

/* color variables included separately for reliability */

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

	html {
	}

	body {
		counter-reset: example figure issue;

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	p {
		margin: 1em 0;
	}

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

	/* Do something nice. */

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

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

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

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

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

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

	img {
		border-style: none;
	}

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


/*
Alternate table alignment rules

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

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

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

Possible extra rowspan handling

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

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

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


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

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

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

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

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

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

		.toc li {
			clear: both;
		}

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

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

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


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

	/* Index Lists: Layout */
	ul.index	  { margin-left: 0; columns: 15em; text-indent: 1em hanging; }
	ul.index li	{ margin-left: 0; list-style: none; break-inside: avoid; }
	ul.index li li { margin-left: 1em; }
	ul.index dl	{ margin-top: 0; }
	ul.index dt	{ margin: .2em 0 .2em 20px;}
	ul.index dd	{ margin: .2em 0 .2em 40px;}
	/* Index Lists: Typography */
	ul.index ul,
	ul.index dl { font-size: smaller; }
	@media not print {
		ul.index li span:not(.dfn-paneled) {
			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 type="text/css">
    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 0125332fd, updated Mon Dec 6 11:46:20 2021 -0800" name="generator">
  <link href="https://wg21.link/P2455" rel="canonical">
  <link href="https://isocpp.org/favicon.ico" rel="icon">
  <meta content="635ef6edd297b5b8936ef838e5a39ede44ea3f66" name="document-revision">
<style>
table, th, tr, td {
  border: 2px solid black !important;
}
@media (prefers-color-scheme: dark) {
  table, th, tr, td {
    border: 2px solid white !important;
  }
}
</style>
<style>/* style-autolinks */

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

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

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

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

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

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

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

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

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

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

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

    --heading-text: #005a9c;

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

    --algo-border: #def;

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

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

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

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

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

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

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

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

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

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

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

    --datacell-border: silver;

    --indexinfo-text: #707070;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        --heading-text: #8af;

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

        --algo-border: #456;

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

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

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

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

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

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

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

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

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

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

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

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

        --datacell-border: silver;

        --indexinfo-text: #aaa;

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

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

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

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

    c-[a] { color: #d33682 } /* Keyword.Declaration */
    c-[b] { color: #d33682 } /* Keyword.Type */
    c-[c] { color: #2aa198 } /* Comment */
    c-[d] { color: #2aa198 } /* Comment.Multiline */
    c-[e] { color: #268bd2 } /* Name.Attribute */
    c-[f] { color: #b58900 } /* Name.Tag */
    c-[g] { color: #cb4b16 } /* Name.Variable */
    c-[k] { color: #d33682 } /* Keyword */
    c-[l] { color: #657b83 } /* Literal */
    c-[m] { color: #657b83 } /* Literal.Number */
    c-[n] { color: #268bd2 } /* Name */
    c-[o] { color: #657b83 } /* Operator */
    c-[p] { color: #657b83 } /* Punctuation */
    c-[s] { color: #6c71c4 } /* Literal.String */
    c-[t] { color: #6c71c4 } /* Literal.String.Single */
    c-[u] { color: #6c71c4 } /* Literal.String.Double */
    c-[ch] { color: #2aa198 } /* Comment.Hashbang */
    c-[cp] { color: #2aa198 } /* Comment.Preproc */
    c-[cpf] { color: #2aa198 } /* Comment.PreprocFile */
    c-[c1] { color: #2aa198 } /* Comment.Single */
    c-[cs] { color: #2aa198 } /* Comment.Special */
    c-[kc] { color: #d33682 } /* Keyword.Constant */
    c-[kn] { color: #d33682 } /* Keyword.Namespace */
    c-[kp] { color: #d33682 } /* Keyword.Pseudo */
    c-[kr] { color: #d33682 } /* Keyword.Reserved */
    c-[ld] { color: #657b83 } /* Literal.Date */
    c-[nc] { color: #268bd2 } /* Name.Class */
    c-[no] { color: #268bd2 } /* Name.Constant */
    c-[nd] { color: #268bd2 } /* Name.Decorator */
    c-[ni] { color: #268bd2 } /* Name.Entity */
    c-[ne] { color: #268bd2 } /* Name.Exception */
    c-[nf] { color: #268bd2 } /* Name.Function */
    c-[nl] { color: #268bd2 } /* Name.Label */
    c-[nn] { color: #268bd2 } /* Name.Namespace */
    c-[py] { color: #268bd2 } /* Name.Property */
    c-[ow] { color: #657b83 } /* Operator.Word */
    c-[mb] { color: #657b83 } /* Literal.Number.Bin */
    c-[mf] { color: #657b83 } /* Literal.Number.Float */
    c-[mh] { color: #657b83 } /* Literal.Number.Hex */
    c-[mi] { color: #657b83 } /* Literal.Number.Integer */
    c-[mo] { color: #657b83 } /* Literal.Number.Oct */
    c-[sa] { color: #6c71c4 } /* Literal.String.Affix */
    c-[sb] { color: #6c71c4 } /* Literal.String.Backtick */
    c-[sc] { color: #6c71c4 } /* Literal.String.Char */
    c-[dl] { color: #6c71c4 } /* Literal.String.Delimiter */
    c-[sd] { color: #6c71c4 } /* Literal.String.Doc */
    c-[se] { color: #6c71c4 } /* Literal.String.Escape */
    c-[sh] { color: #6c71c4 } /* Literal.String.Heredoc */
    c-[si] { color: #6c71c4 } /* Literal.String.Interpol */
    c-[sx] { color: #6c71c4 } /* Literal.String.Other */
    c-[sr] { color: #6c71c4 } /* Literal.String.Regex */
    c-[ss] { color: #6c71c4 } /* Literal.String.Symbol */
    c-[fm] { color: #268bd2 } /* Name.Function.Magic */
    c-[vc] { color: #cb4b16 } /* Name.Variable.Class */
    c-[vg] { color: #cb4b16 } /* Name.Variable.Global */
    c-[vi] { color: #cb4b16 } /* Name.Variable.Instance */
    c-[vm] { color: #cb4b16 } /* Name.Variable.Magic */
    c-[il] { color: #657b83 } /* Literal.Number.Integer.Long */
}
</style>
 <body class="h-entry">
  <div class="head">
   <p data-fill-with="logo"></p>
   <h1 class="p-name no-ref" id="title">P2455R0<br>2021 November 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="2021-12-08">2021-12-08</time></span></h2>
   <div data-fill-with="spec-metadata">
    <dl>
     <dt class="editor">Author:
     <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:brycelelbach@gmail.com">Bryce Adelstein Lelbach (he/him/his) — Library Evolution Chair</a> (<span class="p-org org">NVIDIA</span>)
     <dt>Source:
     <dd><a href="https://github.com/brycelelbach/wg21_p2455_2021_november_library_evolution_poll_outcomes/blob/main/2021_november_library_evolution_poll_outcomes.bs">GitHub</a>
     <dt>Issue Tracking:
     <dd><a href="https://github.com/brycelelbach/wg21_p2455_2021_november_library_evolution_poll_outcomes/issues">GitHub</a>
     <dt>Project:
     <dd>ISO/IEC JTC1/SC22/WG21 14882: Programming Language — C++
     <dt>Audience:
     <dd>WG21
    </dl>
   </div>
   <div data-fill-with="warning"></div>
   <hr title="Separator for header">
  </div>
  <nav data-fill-with="table-of-contents" id="toc">
   <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
   <ol class="toc" role="directory">
    <li><a href="#introduction"><span class="secno">1</span> <span class="content">Introduction</span></a>
    <li><a href="#poll-outcomes"><span class="secno">2</span> <span class="content">Poll Outcomes</span></a>
    <li>
     <a href="#selected-poll-comments"><span class="secno">3</span> <span class="content">Selected Poll Comments</span></a>
     <ol class="toc">
      <li><a href="#poll-1"><span class="secno">3.1</span> <span class="content">Poll 1: <span>[P2465R1]</span> Standard Library Modules <code class="highlight"><c- n>std</c-></code> And <code class="highlight"><c- n>std</c-><c- p>.</c-><c- n>compat</c-></code></span></a>
      <li><a href="#poll-2"><span class="secno">3.2</span> <span class="content">Poll 2: <span>[P2387R2]</span> Pipe Support For User-Defined Range Adaptors</span></a>
      <li><a href="#poll-3"><span class="secno">3.3</span> <span class="content">Poll 3: <span>[P2443R0]</span> <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>chunk_by</c-></code></span></a>
      <li><a href="#poll-4"><span class="secno">3.4</span> <span class="content">Poll 4: <span>[P2442R0]</span> Windowing Range Adaptors: <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>chunk</c-></code> And <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>slide</c-></code></span></a>
      <li><a href="#poll-5"><span class="secno">3.5</span> <span class="content">Poll 5: <span>[P2440R0]</span> <code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>iota</c-></code>, <code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>shift_left</c-></code>, And <code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>shift_right</c-></code></span></a>
      <li><a href="#poll-6"><span class="secno">3.6</span> <span class="content">Poll 6: <span>[P2255R2]</span> A Type Trait To Detect Reference Binding To Temporary</span></a>
      <li><a href="#poll-7"><span class="secno">3.7</span> <span class="content">Poll 7: <span>[P1885R8]</span> Naming Text Encodings To Demystify Them</span></a>
      <li><a href="#poll-8"><span class="secno">3.8</span> <span class="content">Poll 8: <span>[P2419R1]</span> Clarify Handling Of Encodings In Localized Formatting Of Chrono Types</span></a>
      <li><a href="#poll-9"><span class="secno">3.9</span> <span class="content">Poll 9: <span>[P2460R0]</span> Relax Requirements On <code class="highlight"><c- b>wchar_t</c-></code> To Match Existing Practices</span></a>
      <li><a href="#poll-10"><span class="secno">3.10</span> <span class="content">Poll 10: <span>[P2445R0]</span> <code class="highlight"><c- n>forward_like</c-></code></span></a>
      <li><a href="#poll-11"><span class="secno">3.11</span> <span class="content">Poll 11: <span>[P2417R0]</span> A More <code class="highlight"><c- k>constexpr</c-></code> <code class="highlight"><c- n>bitset</c-></code></span></a>
      <li><a href="#poll-12"><span class="secno">3.12</span> <span class="content">Poll 12: <span>[P1841R1]</span> Wording For Individually Specializable Numeric Traits</span></a>
      <li><a href="#poll-13"><span class="secno">3.13</span> <span class="content">Poll 13: <span>[P0627R6]</span> Function To Mark Unreachable Code</span></a>
     </ol>
    <li>
     <a href="#references"><span class="secno"></span> <span class="content">References</span></a>
     <ol class="toc">
      <li><a href="#informative"><span class="secno"></span> <span class="content">Informative References</span></a>
     </ol>
   </ol>
  </nav>
  <main>
   <h2 class="heading settled" data-level="1" id="introduction"><span class="secno">1. </span><span class="content">Introduction</span><a class="self-link" href="#introduction"></a></h2>
   <p>In November 2021, the C++ Library Evolution group conducted a series of
  electronic decision polls <a data-link-type="biblio" href="https://wg21.link/p2454r0">[P2454R0]</a>.
This paper provides the results of those polls and summarizes the results.</p>
   <p>In total, 37 people participated in the polls.
Some participants opted to not vote on some polls.
Thank you to everyone who participated, and to the proposal authors for all
  their hard work!</p>
   <h2 class="heading settled" data-level="2" id="poll-outcomes"><span class="secno">2. </span><span class="content">Poll Outcomes</span><a class="self-link" href="#poll-outcomes"></a></h2>
   <ul>
    <li data-md>
     <p>SF: Strongly Favor.</p>
    <li data-md>
     <p>WF: Weakly Favor.</p>
    <li data-md>
     <p>N: Neutral.</p>
    <li data-md>
     <p>WA: Weakly Against.</p>
    <li data-md>
     <p>SA: Strongly Against.</p>
   </ul>
   <table>
    <tbody>
     <tr>
      <th style="padding-bottom: 10px;">Poll 
      <th>SF 
      <th>WF 
      <th>N 
      <th>WA 
      <th>SA 
      <th>Outcome 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 1: Send <a data-link-type="biblio" href="https://wg21.link/p2465r1">[P2465R1]</a> (Standard Library Modules <code class="highlight"><c- n>std</c-></code> And <code class="highlight"><c- n>std</c-><c- p>.</c-><c- n>compat</c-></code>) to
  Library Working Group for C++23, classified as a focus (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 1
  item). 
      <td>20 
      <td>9 
      <td>1 
      <td>2 
      <td>1 
      <td>Consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 2: Send <a data-link-type="biblio" href="https://wg21.link/p2387r2">[P2387R2]</a> (Pipe Support For User-Defined Range Adaptors) to
  Library Working Group for C++23, classified as an addition (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket
  3 item). 
      <td>15 
      <td>9 
      <td>0 
      <td>0 
      <td>0 
      <td>Unanimous consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 3: Send <a data-link-type="biblio" href="https://wg21.link/p2443r0">[P2443R0]</a> (<code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>chunk_by</c-></code>) to Library Working Group for C++23,
  classified as an addition (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 3 item). 
      <td>14 
      <td>5 
      <td>0 
      <td>0 
      <td>0 
      <td>Unanimous consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 4: Modify <a data-link-type="biblio" href="https://wg21.link/p2442r0">[P2442R0]</a> (Windowing Range Adaptors: <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>chunk</c-></code> And <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>slide</c-></code>) by replacing the current feature test macro with separate
  feature test macros for <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>chunk</c-></code> and <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>slide</c-></code> and then send the
  revised paper to Library Working Group for C++23, classified as an addition
  (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 3 item). 
      <td>14 
      <td>4 
      <td>0 
      <td>0 
      <td>0 
      <td>Unanimous consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 5: Send <a data-link-type="biblio" href="https://wg21.link/p2440r0">[P2440R0]</a> (<code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>iota</c-></code>, <code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>shift_left</c-></code>, And <code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>shift_right</c-></code>) to Library Working Group for C++23, classified as
  an addition (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 3 item). 
      <td>11 
      <td>12 
      <td>0 
      <td>0 
      <td>0 
      <td>Unanimous consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 6: Send <a data-link-type="biblio" href="https://wg21.link/p2255r2">[P2255R2]</a> (A Type Trait To Detect Reference Binding To
  Temporary) to Library Working Group for C++23, classified as an addition
  (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 3 item). 
      <td>14 
      <td>12 
      <td>1 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 7: Send <a data-link-type="biblio" href="https://wg21.link/p1885r8">[P1885R8]</a> (Naming Text Encodings To Demystify Them) to Library
  Working Group for C++23, classified as an addition (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 3 item). 
      <td>11 
      <td>10 
      <td>2 
      <td>2 
      <td>2 
      <td>Consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 8: Send <a data-link-type="biblio" href="https://wg21.link/p2419r1">[P2419R1]</a> (Clarify Handling Of Encodings In Localized Formatting
  Of Chrono Types) to Library Working Group for C++23, classified as an
  improvement of an existing feature (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 2 item). 
      <td>13 
      <td>11 
      <td>1 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 9: Send <a data-link-type="biblio" href="https://wg21.link/p2460r0">[P2460R0]</a> (Relax Requirements On <code class="highlight"><c- b>wchar_t</c-></code> To Match Existing
  Practices) to Library Working Group for C++23, classified as an improvement
  of an existing feature (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 2 item). 
      <td>12 
      <td>15 
      <td>1 
      <td>1 
      <td>0 
      <td>Consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 10: Send <a data-link-type="biblio" href="https://wg21.link/p2445r0">[P2445R0]</a> (<code class="highlight"><c- n>forward_like</c-></code>) to Library Working Group for C++23,
  classified as an addition (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 3 item). 
      <td>14 
      <td>11 
      <td>1 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 11: Send <a data-link-type="biblio" href="https://wg21.link/p2417r0">[P2417R0]</a> (A More <code class="highlight"><c- k>constexpr</c-></code> <code class="highlight"><c- n>bitset</c-></code>) to Library Working
  Group for C++23, classified as an improvement of an existing feature
  (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 2 item). 
      <td>13 
      <td>13 
      <td>3 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 12: Modify <a data-link-type="biblio" href="https://wg21.link/p1841r1">[P1841R1]</a> (Wording For Individually Specializable Numeric
  Traits) by applying <a data-link-type="biblio" href="https://wg21.link/p2485r0">[P2485R0]</a> (Do Not Add <code class="highlight"><c- n>value_exists</c-></code> And <code class="highlight"><c- n>value_or</c-></code> To C++23), and then send the revised paper to Library Working Group for
  C++23, classified as an addition (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket 3 item). 
      <td>13 
      <td>8 
      <td>0 
      <td>0 
      <td>0 
      <td>Unanimous consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 13: Send <a data-link-type="biblio" href="https://wg21.link/p0627r6">[P0627R6]</a> (Function To Mark Unreachable Code), which was
  previously approved and has been modified to remove the message parameter, to
  Library Working Group for C++23, classified as an addition (<a data-link-type="biblio" href="https://wg21.link/p0592r4">[P0592R4]</a> bucket
  3 item). 
      <td>27 
      <td>4 
      <td>1 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
   </table>
   <h2 class="heading settled" data-level="3" id="selected-poll-comments"><span class="secno">3. </span><span class="content">Selected Poll Comments</span><a class="self-link" href="#selected-poll-comments"></a></h2>
   <h3 class="heading settled" data-level="3.1" id="poll-1"><span class="secno">3.1. </span><span class="content">Poll 1: <a data-link-type="biblio" href="https://wg21.link/p2465r1">[P2465R1]</a> Standard Library Modules <code class="highlight"><c- n>std</c-></code> And <code class="highlight"><c- n>std</c-><c- p>.</c-><c- n>compat</c-></code></span><a class="self-link" href="#poll-1"></a></h3>
   <blockquote>
    <p>Given the performance result, I believe this paper provides right solution.
Also, I believe having both <code class="highlight"><c- n>std</c-></code> and <code class="highlight"><c- n>std</c-><c- p>.</c-><c- n>compat</c-></code> modules, is necessary for
preserving namespace hygiene. The alternative of <code class="highlight"><c- k>import</c-> <c- n>std</c-><c- p>;</c-></code> followed by <code class="highlight"><c- k>using</c-> <c- k>namespace</c-> <c- n>std</c-><c- p>;</c-></code> is strictly worse.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Simplicity argues in favor of providing this feature even if we later provide
smaller modules. While the idea of having <code class="highlight"><c- n>std</c-><c- p>.</c-><c- n>foo</c-></code> be such a subset of <code class="highlight"><c- n>std</c-></code> is a good one in general (partly because it might serve to encourage similar
arrangements in user-defined libraries), there is no current plan to create
them, and if any come to be it will not be fatal to have <code class="highlight"><c- n>std</c-><c- p>.</c-><c- n>compat</c-></code> be one
exception to the rule.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>We need something like this badly. It makes sense that there are two modules.
I agree that the "cleaner" option should be easier to type. I also agree that
the "make everything work" option should be a single line of code, and not
two lines (as in a separate module for the global namespace).</p>
    <p>There was a debate over whether the period (as in std.compat) should imply an
increase in specificity or hierarchy depth. In this case, std.compat <code class="highlight"><c- n>does</c-> <c- n>more</c-> <c- n>importing</c-></code> than std, so it is less specific. This might surprise some
users, whose experience in other programming languages with modules might
lead them to expect periods to imply increasing hierarchy depth or
specificity. However, I think having the <code class="highlight"><c- k>import</c-> <c- n>std</c-></code> feature is worth this
minor risk of confusion. C++ does not tie modules to the filesystem or a
namespace hierarchy, so there’s no reason to make periods significant.</p>
    <p>The <code class="highlight"><c- k>import</c-> <c- n>std</c-></code> statement being fewer characters will encourage users to
type <code class="highlight"><c- n>std</c-><c- o>::</c-></code> in front of functions and types. This will make C++ more robust
to any future incompatible changes in the C Standard. It will also make
teaching C++ easier, by removing special cases (if it’s in the Standard
Library, it lives in the <code class="highlight"><c- n>std</c-></code> namespace). I would hope that coding standards
discourage <code class="highlight"><c- k>import</c-> <c- n>std</c-><c- p>.</c-><c- n>compat</c-></code> in favor of <code class="highlight"><c- k>import</c-> <c- n>std</c-></code>."</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’m not happy with the name <code class="highlight"><c- n>std</c-><c- p>.</c-><c- n>compat</c-></code>, but I can live with it. <code class="highlight"><c- n>stdcompat</c-></code> would avoid the whole dot-confusion and I don’t understand why people insist
on the dot.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I like the proposal for its simplicity and that we managed to for once give
the good default syntax space to the modern best practice. I would have
wished for a somewhat more in depth discussion of finer grained modules
(along the lines of prerequisites/dependencies, i.e. <code class="highlight"><c- n>std</c-><c- p>.</c-><c- n>io</c-></code>, <code class="highlight"><c- n>std</c-><c- p>.</c-><c- n>compiler_support</c-></code>, <code class="highlight"><c- n>std</c-><c- p>.</c-><c- n>core</c-></code>, <code class="highlight"><c- n>std</c-><c- p>.</c-><c- n>freestanding</c-></code>, ...) but I am aware
that we did not have time in the C++23 timeframe.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>It will finally provide the standard library module support that was missing
from C++20. Voting weakly in favor because the current scheme makes it
unnecessarily awkward to use types like <code class="highlight"><c- b>int32_t</c-></code>.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a kind of "bare-minimum" modularisation. It’s hard to judge the value
of this, but I suppose we need to do <em>something</em>.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>By examples, this proposal destroys the possibility of having a reasonable meaning for dots in modules names.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <blockquote>
    <p>I am still unconvinced that it’s a good idea to claim the unqualified <code class="highlight"><c- n>std</c-></code> module name.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>Grabbing <code class="highlight"><c- n>std</c-></code> before we have any experience or plan for how module structure
affects evolution of the library is reckless. We will regret this.</p>
    <p>The reason to grab <code class="highlight"><c- n>std</c-></code> now is frivolous.</p>
    <p>"Can teach" <code class="highlight"><c- k>import</c-> <c- n>std</c-><c- p>;</c-></code></p>
    <p>vs</p>
    <p>"Can’t teach" <code class="highlight"><c- k>import</c-> <c- n>std</c-><c- p>.</c-><c- n>all</c-><c- p>;</c-></code></p>
    <p>— Strongly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.2" id="poll-2"><span class="secno">3.2. </span><span class="content">Poll 2: <a data-link-type="biblio" href="https://wg21.link/p2387r2">[P2387R2]</a> Pipe Support For User-Defined Range Adaptors</span><a class="self-link" href="#poll-2"></a></h3>
   <blockquote>
    <p>This is an enabler. This takes of pressure of the standard as users (or third
party providers) can now create their own ranges/views e.g. or also
polyfills/backports of planned features. That this feature was missing form
C++20 was one of my biggest fear when we standardized ranges. I am happy that
we get it now.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I believe this is most important range related paper, as it opens path for
the libraries that defines views that can interoperate with standard ones. It
allows us to escape "the standard should provide every view, otherwise they
will not pipeable" trap.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is the piece that enables interop with standard range adaptor closure
objects; the wording needs a bit more work, but the design is sound.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The author carefully surveys different implementation approaches, and makes a
reasonable decision. The only reason I’m not voting SF is because I’m not a
ranges implementation expert.</p>
    <p>The proposed <code class="highlight"><c- n>bind_back</c-></code> function is a helpful utility that deserves
standardization, just like <code class="highlight"><c- n>bind_front</c-></code>. I appreciate how the author slotted
the <code class="highlight"><c- n>bind_back</c-></code> wording into the <code class="highlight"><c- n>bind_front</c-></code> clause with minimal wording
changes, and renamed the clause to describe both.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>The pipe syntax can’t be taken seriously so long as it is restricted to
standard-library adaptors; one can’t write a template that applies an
arbitrary adaptor using the syntax if it’s not reliably available. However,
I am not well-informed about the details of the design tradeoffs presented in
the paper.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.3" id="poll-3"><span class="secno">3.3. </span><span class="content">Poll 3: <a data-link-type="biblio" href="https://wg21.link/p2443r0">[P2443R0]</a> <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>chunk_by</c-></code></span><a class="self-link" href="#poll-3"></a></h3>
   <blockquote>
    <p>This is an immediately useful feature that comes up regularly in intermediate
students code.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a quite useful range adaptor and has been proven in the field in
ranges v3.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a feature that will help make ranges more usable and complete in C++23.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is one of the many steps in filling out ranges.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.4" id="poll-4"><span class="secno">3.4. </span><span class="content">Poll 4: <a data-link-type="biblio" href="https://wg21.link/p2442r0">[P2442R0]</a> Windowing Range Adaptors: <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>chunk</c-></code> And <code class="highlight"><c- n>views</c-><c- o>::</c-><c- n>slide</c-></code></span><a class="self-link" href="#poll-4"></a></h3>
   <blockquote>
    <p>A sensible and uncontroversial standard view.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Useful functionality, well specified.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Extending ranges will help more developers to be pulled towards it</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I have not followed this paper, although the semantics seem eminently obvious.</p>
    <p>— Did Not Participate</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.5" id="poll-5"><span class="secno">3.5. </span><span class="content">Poll 5: <a data-link-type="biblio" href="https://wg21.link/p2440r0">[P2440R0]</a> <code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>iota</c-></code>, <code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>shift_left</c-></code>, And <code class="highlight"><c- n>ranges</c-><c- o>::</c-><c- n>shift_right</c-></code></span><a class="self-link" href="#poll-5"></a></h3>
   <blockquote>
    <p>There should be a range algorithm for every one of the iterator algorithms in
the Standard Library. This is a step in that direction.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>These are features that will help make ranges more usable and complete in
C++23. I’m convinced by the author’s argument that <code class="highlight"><c- n>shift_left</c-></code> and <code class="highlight"><c- n>shift_right</c-></code> do not need to be changed to return the original end of the
range.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>It is unfortunate to have duplicate versions of all algorithms, but it is a
simplification for it to actually be all of them rather than most of them.
The analysis of the <code class="highlight"><c- n>shift_left</c-></code> return value is correct, even if the result
is not perfectly easy to use in all cases.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Good to continue rangifying the algorithms we missed.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.6" id="poll-6"><span class="secno">3.6. </span><span class="content">Poll 6: <a data-link-type="biblio" href="https://wg21.link/p2255r2">[P2255R2]</a> A Type Trait To Detect Reference Binding To Temporary</span><a class="self-link" href="#poll-6"></a></h3>
   <blockquote>
    <p>We have here a rare opportunity to actually do damage to the perennial
dangling-reference pitfall in C++ without any false positives.  Plausible
language solutions would be either incomplete or no more automatic than using
a trait.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Lets us take code that currently dangles and make it not compile. Seems
great. Would be better if this were unnecessary and instead somehow
detectable by the language, but until that happens, this is a worthwhile
substitute.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a trait that is next to impossible to get right outside of the
standard library, so it should definitely be provided by us.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This fixes the reported problem. I’m not thrilled that we have to solve it
this way, but I have no better suggestion either.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This proposes a very clever facility that experts can use to protect against
a small subset of value lifetime errors in C++ programs. It is one of a
number of library and language papers which attempt to tackle C++'s lack of
lifetime annotation or analysis in a piecemeal fashion. The new facility will
help users avoid accidentally-dangling references, but at the cost of adding
yet another complex subtlety for library authors.</p>
    <p>— Neutral</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.7" id="poll-7"><span class="secno">3.7. </span><span class="content">Poll 7: <a data-link-type="biblio" href="https://wg21.link/p1885r8">[P1885R8]</a> Naming Text Encodings To Demystify Them</span><a class="self-link" href="#poll-7"></a></h3>
   <blockquote>
    <p>I strongly support this paper.</p>
    <p>I implemented <a data-link-type="biblio" href="https://wg21.link/p1885r8">[P1885R8]</a>'s backing compiler technology in all public-facing
compilers I could get my hands on (Clang and its derivatives as well as GCC).
I also - after much gnashing of teeth and over a year of waiting - got
Microsoft to implement it and ship it in their first version of the VS2022
Visual C++ compiler. P1885 is an accurate capturing of the status quo for how
encodings are detected on platforms. It is not the end-all be-all way to
determine encoding names, but asking for anything more is - quite literally -
impossible to force implementation’s hands to do. This is rooted in the POSIX
specification, the C specification, and several of the vendors who do not
provide equivalent functionality to unambiguously ID the encodings used on
those platforms and therefore must rely on a combination of names, platform
hints, and more.</p>
    <p><a data-link-type="biblio" href="https://wg21.link/p1885r8">[P1885R8]</a> takes care of providing portable names. For the <strong>vast majority</strong> of use cases, <a data-link-type="biblio" href="https://wg21.link/p1885r8">[P1885R8]</a> gives the user a way to detect the encodings they
could possibly care about, and allows them to act on that information
(including at compile-time) in a way that is makes it easy to write
user-friendly libraries. I would know, because I had to spend an inordinate
amount of time reimplementing exactly what was in <a data-link-type="biblio" href="https://wg21.link/p1885r8">[P1885R8]</a> for both the
compiler-side (literal encodings) and runtime (in my own now-deployed
libraries). Platform hints still must be the domain of the user to take care
of, wherein the subtleties of using e.g. and IBM-based CN or JP encoding
versus a Microsoft-based CN or JP must be captured through platform-specific
information that cannot be portably serialized without asking standard
librarians to provide extra overhead in their implementations. In this
manner, <a data-link-type="biblio" href="https://wg21.link/p1885r8">[P1885R8]</a> covers a large number of use cases while leaving niche
cases to platform specifics, which is a marked and demonstrable improvement
for most individuals who are trying to write Unicode and non-ASCII-friendly
software in this day and age.</p>
    <p>Asides from this, there are rumblings (particularly in <a data-link-type="biblio" href="https://wg21.link/p2491r0">[P2491R0]</a>) that,
perhaps, the IANA database set is not enough, or that because IANA
specifically states that it is an "octet based" encoding name registry, that
each definition there applies to the # of bytes that should logically be
represented. This has caused some consternation: for example, if wchar_t is
represented by a 32-bit number, but someone puts UTF-16 into it, how can it
possibly be called "UTF-16" by IANA standards, since it has unused octets in
its higher bytes? Does this not make the identification less useful?</p>
    <p>I find this characterization to be extremely problematic from the get-go. Not
only is using an octet-only definition limited and dangerous for portability
(because you now have to expose the rather serious concern that <code class="highlight"><c- n>CHAR_BIT</c-> <c- o>!=</c-> <c- mi>8</c-></code> on all C and C++ platforms), it also forces an extreme amount of
duplication throughout the platform. For example, UTF-8 is an 8-bit-byte
based encoding. Already, I <strong>know</strong> of platforms that put UTF-8 code units in
the lower 8 bits of 32-bit sized <code class="highlight"><c- b>wchar_t</c-></code>s on their <code class="highlight"><c- n>CHAR_BIT</c-> <c- o>==</c-> <c- mi>32</c-></code> chips.
Are we going to define "UTF-8.32" to encapsulate this fact? What about every
other encoding? Is "ASCII.32" now on the table? What happens if they have <code class="highlight"><c- n>CHAR_BIT</c-> <c- o>==</c-> <c- mi>16</c-></code>, and put ASCII in their <code class="highlight"><c- b>char</c-></code>? "UTF7-IMAP.C16"?</p>
    <p>Down this direction lies a decimation of usefulness for <a data-link-type="biblio" href="https://wg21.link/p1885r8">[P1885R8]</a>. Everyone
will have to start checking <code class="highlight"><c- n>CHAR_BIT</c-></code>, and std::endian, and SEVERAL other
factors to find out if they have the exactly right-sized-and-right-encoded
value. It also does not encapsulate existing practice: I already have a
counter-example in the Digital Signal Processor I spoke of earlier that puts
UTF-8 into 32-bit <code class="highlight"><c- b>wchar_t</c-></code>. They do not call this "UTF-8.32", it is simply
UTF-8 to them. Why?</p>
    <p>Because they interpret the encoding form to apply to each code unit, not to
each octet.</p>
    <p>A code unit-based interpretation is much more fruitful. Strongly in favor.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>There is no good solution for providing names for all encodings because the
same name has been reused to mean different things. The history of text is
full of problems. This proposal however, provides enough information to code
that the compiler knows such that literals can actually be decoded.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This paper provides important APIs for identifying standard encodings and is
critical for building higher level text processing facilities.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Seems reasonable, but experimenting with this will be required to make sure
we got it right.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I have some concerns about coupling ourselves to the IANA database, but it
seems that rumours of its death were exaggerated, so maybe it’s OK. It’s a
hard problem, I hope this is the right solution.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>The new API gives access to compilation information that is otherwise very
difficult to obtain. It can be used efficiently at compile time. It makes
effective use of the only recognized registry for naming text encodings in a
stable way. The weaknesses in the proposal arise from the fact that the way
that encodings are named and specified in the IANA registry do not exactly
align with the way that text is modelled in C++, but we’ve done our best to
deal with the incompatibilities. This proposal isn’t perfect, but I don’t
know how to make it any better.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I remain concerned about:</p>
    <p>1) use of the IANA character registry as the sole source of named encodings,
2) the special case handling of UTF-16 and UTF-32,
3) the lack of implementation experience in a shipping compiler,
4) how wide character encodings are handled, and
5) whether the proposed <code class="highlight"><c- n>text_encoding</c-></code> type will be useful for other
   envisioned encoding identification purposes (e.g., as tag types for encoding
   sensitive function templates).</p>
    <p>I think many of these issues are fixable, so long as they are addressed for
C++23.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>I don’t like the spelling of <code class="highlight"><c- n>text_encoding</c-><c- o>::</c-><c- n>id</c-></code> enumerators; there seems to
be no consistency in casing and the style - if a single one even exists - is
entirely inconsistent with the rest of the standard library. Sure, it’s from
the IANA database, but we seem to have no problem doing other massages on the
names already since we are dropping the "cs" prefix and renaming two
encodings.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>This feature is every useful (see for example next poll) and I believe should
be included in standard. However, after reading <a data-link-type="biblio" href="https://wg21.link/p2491r0">[P2491R0]</a>, I agree that
this concern need resolution. This may be as simple, as limiting returning
IANA schemes to <code class="highlight"><c- k>sizeof</c-><c- p>(</c-><c- n>char_size</c-><c- p>)</c-> <c- o>==</c-> <c- mi>1</c-></code>, i.e. leaving <code class="highlight"><c- n>wide_literal</c-></code> implementation defined now.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>The concerns expressed in <a data-link-type="biblio" href="https://wg21.link/p2491r0">[P2491R0]</a> are very real. When <code class="highlight"><c- b>wchar_t</c-></code> is in use
and is of the right size, it is plausible to use names like UTF-16 to refer
to an encoding form (trivially encoded as a sequence of <code class="highlight"><c- b>wchar_t</c-></code> values)
rather than an encoding scheme, but that would require weakening the focus on
IANA in P1885 and would have only a weak connection to the intended utilities
like iconv that plainly interpret such names as referring to an encoding
scheme.  Implementations can specify that functions like iconv work with <code class="highlight"><c- b>wchar_t</c-></code> arrays without (and are not assisted in doing so by) any statement
about object representations in the standard.</p>
    <p>It is also true that inventiveness in a domain already so chaotic is plainly
undesirable. While it might merely reaffirm <a data-link-type="biblio" href="https://wg21.link/p1885r8">[P1885R8]</a>'s practical direction
with a different interpretation, it seems that we need to reconsider the
choices made in the extremely troublesome area of non-octet-based encoding
schemes.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>See <a data-link-type="biblio" href="https://wg21.link/p2491r0">[P2491R0]</a> (Text Encodings Follow-Up) for details. In short:</p>
    <ul>
     <li data-md>
      <p><a data-link-type="biblio" href="https://wg21.link/p1885r8">[P1885R8]</a> re-uses the encoding "UTF16" for a different purpose, which
causes confusion.</p>
     <li data-md>
      <p><a data-link-type="biblio" href="https://wg21.link/p1885r8">[P1885R8]</a> cannot properly represent the UCS-2 wide encoding used on
Microsoft Windows before the switch to UTF-16.</p>
     <li data-md>
      <p><a data-link-type="biblio" href="https://wg21.link/p1885r8">[P1885R8]</a> attempts to specify object representation, which breaks an
important C++ abstraction barrier</p>
    </ul>
    <p>— Strongly Against</p>
   </blockquote>
   <blockquote>
    <p>The observations in <a data-link-type="biblio" href="https://wg21.link/p2491r0">[P2491R0]</a> are on point. The present proposal disregards
an existing ISO standard in favour of "existing practice", which is not a
step we should take lightly, and it could easily increase the existing
confusing landscape around the terms related to "UTF-16". Finally, <a data-link-type="biblio" href="https://wg21.link/p2491r0">[P2491R0]</a>'s point that the library is the wrong place to talk about object
representation is serious and warrants more work.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.8" id="poll-8"><span class="secno">3.8. </span><span class="content">Poll 8: <a data-link-type="biblio" href="https://wg21.link/p2419r1">[P2419R1]</a> Clarify Handling Of Encodings In Localized Formatting Of Chrono Types</span><a class="self-link" href="#poll-8"></a></h3>
   <blockquote>
    <p>This proposal relaxes requirements on implementations, giving them the option
to provide better results if they want to. It is uniformly applicable across
all Unicode encoding forms. It resolves the LWG issue adequately.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This seems to be the least worst solution to the problem, and we need one now.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Looks ok, although I’d prefer solving the general problem of mixing literal
and locale-dependent encodings.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Handling a mismatch between the literal encoding and the locale’s encoding
requires a great deal of machinery and discipline, but since in practice the
literal encoding must be presumed for all strings of whichever character
type, it is obviously the correct approach to select the characters from the
locale and the encoding from the implementation.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I remain concerned about use of the literal encoding as a proxy for the
encoding of the output.</p>
    <p>— Neutral</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.9" id="poll-9"><span class="secno">3.9. </span><span class="content">Poll 9: <a data-link-type="biblio" href="https://wg21.link/p2460r0">[P2460R0]</a> Relax Requirements On <code class="highlight"><c- b>wchar_t</c-></code> To Match Existing Practices</span><a class="self-link" href="#poll-9"></a></h3>
   <blockquote>
    <p>Admitting that <code class="highlight"><c- b>wchar_t</c-></code> is almost always UTF-16, since it’s almost never
used on POSIX systems, seems long overdue. This is one small thing, but
fixing this helps in cleaning up treatment of text literals throughout the
standard.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The requirements on <code class="highlight"><c- b>wchar_t</c-></code> have never been useful in practice and there
are platforms where no conforming implementation has ever existed.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Useful relaxation of requirements. We want C++ to be suitable for development
on a major platform.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Bringing <code class="highlight"><c- b>wchar_t</c-></code>'s standardization in line with its actual real world usage
is probably a good thing.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>There is of course fundmentally no good answer here now. The adoption of
16-bit <code class="highlight"><c- b>wchar_t</c-></code> on Windows <em>was</em> an attempt to satisfy [basic.fundamental]/8
and was merely overtaken by events. Changing the wording in this trivial
fashion does not really fix anything, since there is no reasonable "execution
wide-character set" for Windows that satisfies the same outdated requirement.
To do better would require a C ABI break that will never happen, or else the
provision of a <code class="highlight"><c- b>wchar_t</c-></code> type and two new sets of C library functions (one
for <code class="highlight"><c- b>wchar_t</c-></code> as UCS-4 and one for <code class="highlight"><c- b>wchar_t</c-></code> as UTF-16); the only alternative
(which is correct but not better) is to simply indicate in the standard that
wchar_t is just another code-unit type whose library functions are not
portably usable.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>The standard should take a clear stance on whether UTF-16 as a <code class="highlight"><c- b>wchar_t</c-></code> encoding is ok or not. If it’s ok, a substantial overhaul of the relevant
library facilities (some of them inherited from C) is needed, which this
paper does not offer. If it’s not ok, we don’t need this paper. Allowing
UTF-16 as a literal encoding (which this paper achieves) but then disallowing
that same encoding for the entirety of the standard library is unwise.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.10" id="poll-10"><span class="secno">3.10. </span><span class="content">Poll 10: <a data-link-type="biblio" href="https://wg21.link/p2445r0">[P2445R0]</a> <code class="highlight"><c- n>forward_like</c-></code></span><a class="self-link" href="#poll-10"></a></h3>
   <blockquote>
    <p>Already using it, can’t imagine this not being in <code class="highlight"><c- n>std</c-><c- o>::</c-></code>.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Despite the fact, that this paper introduce 3rd independent way of forwarding
in standard, I think that it is necessary. Especially when the number of
cases when this is needed will be dramatically increased by deducing this.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The deducing-this feature is, not without reason, quite complicated; we need
features like this to minimize the complexity for programmers.  The analysis
is suitably exhaustive for something that will be used ubiquitously in
exactly the situations where all corner cases will be exercised without
direct human checking.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’m really torn on this one because I find its value to be quite a bit
overstated, despite having clear use-cases.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>The gap this paper fills was not large until the adoption of explicit this
parameter.</p>
    <p>— Neutral</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.11" id="poll-11"><span class="secno">3.11. </span><span class="content">Poll 11: <a data-link-type="biblio" href="https://wg21.link/p2417r0">[P2417R0]</a> A More <code class="highlight"><c- k>constexpr</c-></code> <code class="highlight"><c- n>bitset</c-></code></span><a class="self-link" href="#poll-11"></a></h3>
   <blockquote>
    <p>Bitsets are important building blocks for low-level applications. The more
here is constexpr, the better. Especially if you want to gain more foothold
on e.g. embedded systems ...</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>To me bitset is an essential building block for flags/masks that should
replace int/enum-based flags. Marking almost all operations of bitset
constexpr brings us closer to abandoning "unsafe" practices.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>We do constexpr bitset operations, but implemented our own. This may
eliminate the need for that.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Everything that can be constexpr should be constexpr.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>There’s no reason that this shouldn’t be usable at compile time.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I think this is a (minor) implementer burden, without providing much value to
users. In my experience, bitset isn’t used much in the wild.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>I was for, but some library implementers pointed out issued with the hash
functions, and they are still in the proposal. I’m reluctant to back a
library feature our implementers are not comfortable with</p>
    <p>— Neutral</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.12" id="poll-12"><span class="secno">3.12. </span><span class="content">Poll 12: <a data-link-type="biblio" href="https://wg21.link/p1841r1">[P1841R1]</a> Wording For Individually Specializable Numeric Traits</span><a class="self-link" href="#poll-12"></a></h3>
   <blockquote>
    <p>The Standard Library desperately needs individual numeric traits that are
SFINAE friendly. The new floating-point constants and naming improvements
will make it easier to write more portable numerical algorithms for non-IEEE
754 types. I also approve of the removal of <code class="highlight"><c- n>value_exists</c-></code> and <code class="highlight"><c- n>value_or</c-></code> from
the proposal.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is quite an improvement on the aging design of <code class="highlight"><c- n>numeric_limits</c-></code> - which
IMHO should be deprecated immediately after this has been adopted.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>It is unfortunate to introduce further duplicate facilities into the standard
library, but the motivation for doing so in this case is sound.  There are
several wording issues in the current version, but they can plainly be
addressed by LWG with perhaps some minor questions to lib-ext@.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is yet another work around for having a lack of proper static
customization facility in the language.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <h3 class="heading settled" data-level="3.13" id="poll-13"><span class="secno">3.13. </span><span class="content">Poll 13: <a data-link-type="biblio" href="https://wg21.link/p0627r6">[P0627R6]</a> Function To Mark Unreachable Code</span><a class="self-link" href="#poll-13"></a></h3>
   <blockquote>
    <p>Having an explicit, standard means of expressing undefined behavior allows
implementations to issue warnings for unconditional undefined behavior while
(optionally) emitting traps for statements incorrectly marked unreachable.
Anyone who prefers the defined trap in all cases can call <code class="highlight"><c- n>abort</c-></code>.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I have comprehensive experience with the "compiler magic less" implementation
of <code class="highlight"><c- n>unreachable</c-></code> - this function is essential in documenting impossible
values/finding bugs.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This function reflects well what implementations already provide, without
overstepping by asking for additional features (see e.g., Section 4.2,
"Diagnostic string"). It’s a much more readable and teachable interface than <code class="highlight"><c- kr>__assume</c-><c- p>(</c->false<c- p>)</c-></code> or the contract form <code class="highlight"><c- p>[[</c-><c- n>assert</c-> <c- nl>axiom</c-><c- p>:</c-> false<c- p>]]</c-></code>. Regarding
contract forms in general, I like that calling <code class="highlight"><c- n>unreachable</c-></code> is undefined
behavior, whereas failing a contract assertion might not be.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The message based unreachable doesn’t seem super important, so I’m fine
pushing through unreachable without the message.</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-p0592r4">[P0592R4]
   <dd>Ville Voutilainen. <a href="https://wg21.link/p0592r4"><cite>To boldly suggest an overall plan for C++23</cite></a>. 25 November 2019. URL: <a href="https://wg21.link/p0592r4">https://wg21.link/p0592r4</a>
   <dt id="biblio-p0627r6">[P0627R6]
   <dd>Jens Maurer. <a href="https://wg21.link/p0627r6"><cite>Function to mark unreachable code</cite></a>. 25 October 2021. URL: <a href="https://wg21.link/p0627r6">https://wg21.link/p0627r6</a>
   <dt id="biblio-p1841r1">[P1841R1]
   <dd>Walter E Brown. <a href="https://wg21.link/p1841r1"><cite>Wording for Individually Specializable Numeric Traits</cite></a>. 15 May 2020. URL: <a href="https://wg21.link/p1841r1">https://wg21.link/p1841r1</a>
   <dt id="biblio-p1885r8">[P1885R8]
   <dd>Corentin Jabot, Peter Brett. <a href="https://wg21.link/p1885r8"><cite>Naming Text Encodings to Demystify Them</cite></a>. 13 October 2021. URL: <a href="https://wg21.link/p1885r8">https://wg21.link/p1885r8</a>
   <dt id="biblio-p2255r2">[P2255R2]
   <dd>Tim Song. <a href="https://wg21.link/p2255r2"><cite>A type trait to detect reference binding to temporary</cite></a>. 14 October 2021. URL: <a href="https://wg21.link/p2255r2">https://wg21.link/p2255r2</a>
   <dt id="biblio-p2387r2">[P2387R2]
   <dd>Barry Revzin. <a href="https://wg21.link/p2387r2"><cite>Pipe support for user-defined range adaptors</cite></a>. 18 October 2021. URL: <a href="https://wg21.link/p2387r2">https://wg21.link/p2387r2</a>
   <dt id="biblio-p2417r0">[P2417R0]
   <dd>Daniil Goncharov. <a href="https://wg21.link/p2417r0"><cite>A more constexpr bitset</cite></a>. 24 July 2021. URL: <a href="https://wg21.link/p2417r0">https://wg21.link/p2417r0</a>
   <dt id="biblio-p2419r1">[P2419R1]
   <dd>Victor Zverovich, Peter Brett. <a href="https://wg21.link/p2419r1"><cite>Clarify handling of encodings in localized formatting of chrono types</cite></a>. 19 September 2021. URL: <a href="https://wg21.link/p2419r1">https://wg21.link/p2419r1</a>
   <dt id="biblio-p2440r0">[P2440R0]
   <dd>Tim Song. <a href="https://wg21.link/p2440r0"><cite>ranges::iota, ranges::shift_left, and ranges::shift_right</cite></a>. 13 September 2021. URL: <a href="https://wg21.link/p2440r0">https://wg21.link/p2440r0</a>
   <dt id="biblio-p2442r0">[P2442R0]
   <dd>Tim Song. <a href="https://wg21.link/p2442r0"><cite>Windowing range adaptors: views::chunk and views::slide</cite></a>. 14 September 2021. URL: <a href="https://wg21.link/p2442r0">https://wg21.link/p2442r0</a>
   <dt id="biblio-p2443r0">[P2443R0]
   <dd>Tim Song. <a href="https://wg21.link/p2443r0"><cite>views::chunk_by</cite></a>. 15 September 2021. URL: <a href="https://wg21.link/p2443r0">https://wg21.link/p2443r0</a>
   <dt id="biblio-p2445r0">[P2445R0]
   <dd>Gašper Ažman. <a href="https://wg21.link/p2445r0"><cite>forward_like</cite></a>. 12 October 2021. URL: <a href="https://wg21.link/p2445r0">https://wg21.link/p2445r0</a>
   <dt id="biblio-p2454r0">[P2454R0]
   <dd>Bryce Adelstein Lelbach. <a href="https://wg21.link/p2454r0"><cite>2021 November Library Evolution Polls</cite></a>. 3 November 2021. URL: <a href="https://wg21.link/p2454r0">https://wg21.link/p2454r0</a>
   <dt id="biblio-p2460r0">[P2460R0]
   <dd>Corentin Jabot. <a href="https://wg21.link/p2460r0"><cite>Relax requirements on wchar_t to match existing practices</cite></a>. 9 October 2021. URL: <a href="https://wg21.link/p2460r0">https://wg21.link/p2460r0</a>
   <dt id="biblio-p2465r1">[P2465R1]
   <dd>Stephan T. Lavavej, Gabriel Dos Reis, Bjarne Stroustrup, Jonathan Wakely. <a href="https://wg21.link/p2465r1"><cite>Standard Library Modules std and std.compat</cite></a>. 13 October 2021. URL: <a href="https://wg21.link/p2465r1">https://wg21.link/p2465r1</a>
   <dt id="biblio-p2485r0">[P2485R0]
   <dd>Jonathan Wakely. <a href="https://wg21.link/p2485r0"><cite>Do not add value_exists and value_or to C++23</cite></a>. 1 November 2021. URL: <a href="https://wg21.link/p2485r0">https://wg21.link/p2485r0</a>
   <dt id="biblio-p2491r0">[P2491R0]
   <dd>Jens Maurer. <a href="https://wg21.link/p2491r0"><cite>Text encodings follow-up</cite></a>. 15 November 2021. URL: <a href="https://wg21.link/p2491r0">https://wg21.link/p2491r0</a>
  </dl>