<!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>P2262R0: 2020 Fall 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,
	#subtitle {
		/* #subtitle 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: none;
		border-bottom: 1px solid #707070;
		border-bottom: 1px solid var(--a-normal-underline);
		/* Need a bit of extending for it to look okay */
		padding: 0 1px 0;
		margin: 0 -1px 0;
	}
	a:visited {
		color: #034575;
		color: var(--a-visited-text);
		border-bottom-color: #bbb;
		border-bottom-color: var(--a-visited-underline);
	}

	/* Use distinguishing colors when user is interacting with the link */
	a[href]:focus,
	a[href]:hover {
		background: #f8f8f8;
		background: rgba(75%, 75%, 75%, .25);
		background: var(--a-hover-bg);
		border-bottom-width: 3px;
		margin-bottom: -2px;
	}
	a[href]:active {
		color: #c00;
		color: var(--a-active-text);
		border-color: #c00;
		border-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-top: 0.1rem;
		/* Larger, more consistently-sized click target */
		display: block;
		/* 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: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 4e8dd937, updated Fri Nov 13 16:49:31 2020 -0800" name="generator">
  <link href="https://wg21.link/P2262R0" rel="canonical">
  <link href="https://isocpp.org/favicon.ico" rel="icon">
<style>
pre {
  margin-top: 0px;
  margin-bottom: 0px;
}
.ins, ins, ins *, span.ins, span.ins * {
  background-color: rgb(200, 250, 200);
  color: rgb(0, 136, 0);
  text-decoration: none;
}
.del, del, del *, span.del, span.del * {
  background-color: rgb(250, 200, 200);
  color: rgb(255, 0, 0);
  text-decoration: line-through;
  text-decoration-color: rgb(255, 0, 0);
}
math, span.math {
  font-family: serif;
  font-style: italic;
}
ul {
  list-style-type: "— ";
}
blockquote {
  counter-reset: paragraph;
}
div.numbered, div.newnumbered {
  margin-left: 2em;
  margin-top: 1em;
  margin-bottom: 1em;
}
div.numbered:before, div.newnumbered:before {
  position: absolute;
  margin-left: -2em;
  display-style: block;
}
div.numbered:before {
  content: counter(paragraph);
  counter-increment: paragraph;
}
div.newnumbered:before {
  content: "�";
}
div.numbered ul, div.newnumbered ul {
  counter-reset: list_item;
}
div.numbered li, div.newnumbered li {
  margin-left: 3em;
}
div.numbered li:before, div.newnumbered li:before {
  position: absolute;
  margin-left: -4.8em;
  display-style: block;
}
div.numbered li:before {
  content: "(" counter(paragraph) "." counter(list_item) ")";
  counter-increment: list_item;
}
div.newnumbered li:before {
  content: "(�." counter(list_item) ")";
  counter-increment: list_item;
}
</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: #707070;
    --a-visited-text: var(--a-normal-text);
    --a-visited-underline: #bbb;
    --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-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">P2262R0<br>2020 Fall Library Evolution Poll Outcomes</h1>
   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Published Proposal, <time class="dt-updated" datetime="2020-12-02">2020-12-02</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_p2262_2020_fall_library_evolution_poll_outcomes/blob/main/2020_fall_library_evolution_poll_outcomes.bs">GitHub</a>
     <dt>Issue Tracking:
     <dd><a href="https://github.com/brycelelbach/wg21_p2233_2020_fall_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="#summarized-poll-results"><span class="secno">2</span> <span class="content">Summarized Poll Results</span></a>
    <li><a href="#summarized-outcomes"><span class="secno">3</span> <span class="content">Summarized Outcomes</span></a>
    <li>
     <a href="#detailed-results"><span class="secno">4</span> <span class="content">Detailed Poll Results and Selected Comments</span></a>
     <ol class="toc">
      <li>
       <a href="#executor-polls"><span class="secno">4.1</span> <span class="content">Executor Polls</span></a>
       <ol class="toc">
        <li><a href="#poll-0"><span class="secno">4.1.1</span> <span class="content">Poll 0</span></a>
        <li><a href="#poll-1"><span class="secno">4.1.2</span> <span class="content">Poll 1</span></a>
        <li><a href="#poll-2"><span class="secno">4.1.3</span> <span class="content">Poll 2</span></a>
        <li><a href="#poll-3"><span class="secno">4.1.4</span> <span class="content">Poll 3</span></a>
        <li><a href="#poll-4"><span class="secno">4.1.5</span> <span class="content">Poll 4</span></a>
        <li><a href="#poll-5"><span class="secno">4.1.6</span> <span class="content">Poll 5</span></a>
       </ol>
      <li>
       <a href="#other-polls"><span class="secno">4.2</span> <span class="content">Other Polls</span></a>
       <ol class="toc">
        <li><a href="#poll-6"><span class="secno">4.2.1</span> <span class="content">Poll 6</span></a>
        <li><a href="#poll-7"><span class="secno">4.2.2</span> <span class="content">Poll 7</span></a>
        <li><a href="#poll-8"><span class="secno">4.2.3</span> <span class="content">Poll 8</span></a>
       </ol>
     </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 Fall 2020, the C++ Library Evolution group took a series of electronic
  decision polls <a data-link-type="biblio" href="#biblio-p2233r3">[P2233R3]</a>.
This paper provides the results of those polls and summarizes the results.</p>
   <p>In total, 49 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="summarized-poll-results"><span class="secno">2. </span><span class="content">Summarized Poll Results</span><a class="self-link" href="#summarized-poll-results"></a></h2>
   <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 0: Remove implicit adaptation from <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors) by applying <a data-link-type="biblio" href="#biblio-p2235r0">[P2235R0]</a> to <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a>, which will make <code class="highlight"><c- n>schedule</c-></code> only take <code class="highlight"><c- n>scheduler</c-></code>s,
  make <code class="highlight"><c- n>execute</c-></code> only take <code class="highlight"><c- n>executor</c-></code>s, make <code class="highlight"><c- n>sender</c-></code> and <code class="highlight"><c- n>receiver</c-></code> operations
  like <code class="highlight"><c- n>connect</c-></code> only take <code class="highlight"><c- n>sender</c-></code>s and <code class="highlight"><c- n>receiver</c-></code>s, and add explicit
  adaptation from <code class="highlight"><c- n>executor</c-></code> to <code class="highlight"><c- n>scheduler</c-></code> (<code class="highlight"><c- n>make_scheduler_from_executor</c-></code>)
  but not vice versa. 
      <td>21 
      <td>15 
      <td>0 
      <td>0 
      <td>0 
      <td>Unanimous consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 1: Use one class for each individual trait instead of combined traits
  classes (<code class="highlight"><c- n>sender_traits</c-></code>, etc) in <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors). 
      <td>7 
      <td>7 
      <td>7 
      <td>5 
      <td>2 
      <td>No consensus. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 2: Remove <code class="highlight"><c- n>static_thread_pool</c-></code> from <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors).
  It may be pursued in a follow-on proposal. 
      <td>8 
      <td>11 
      <td>4 
      <td>7 
      <td>2 
      <td>Weak consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 3: Remove <code class="highlight"><c- n>any_executor</c-></code> from <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors).
  It may be pursued in a follow-on proposal. 
      <td>10 
      <td>9 
      <td>4 
      <td>4 
      <td>2 
      <td>Consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 4: Remove <code class="highlight"><c- n>any_executor</c-><c- o>::</c-><c- n>target</c-></code> and <code class="highlight"><c- n>any_executor</c-><c- o>::</c-><c- n>target_type</c-></code> from <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors). 
      <td>12 
      <td>10 
      <td>4 
      <td>2 
      <td>0 
      <td>Consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 5: <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors) is sufficiently mature that we should aim
  to ship it in C++23. 
      <td>10 
      <td>12 
      <td>7 
      <td>10 
      <td>1 
      <td>Weak consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 6: Send <a data-link-type="biblio" href="#biblio-p2212r1">[P2212R1]</a> (Relax Requirements for <code class="highlight"><c- n>time_point</c-><c- o>::</c-><c- n>clock</c-></code>) to LWG
  for C++23, classified as an improvement of an existing feature (<a data-link-type="biblio" href="#biblio-p0592r4">[P0592R4]</a> bucket 2 item). 
      <td>18 
      <td>13 
      <td>3 
      <td>0 
      <td>0 
      <td>Strong consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 7: Send <a data-link-type="biblio" href="#biblio-p2166r1">[P2166R1]</a> (Prohibit <code class="highlight"><c- n>basic_string</c-></code> and <code class="highlight"><c- n>basic_string_view</c-></code> Construction from <code class="highlight"><c- k>nullptr</c-></code>) to LWG for C++23, classified as an improvement
  of an existing feature (<a data-link-type="biblio" href="#biblio-p0592r4">[P0592R4]</a> bucket 2 item). 
      <td>15 
      <td>18 
      <td>2 
      <td>2 
      <td>1 
      <td>Consensus in favor. 
     <tr>
      <td style="padding-bottom: 16px;"> Poll 8: Send <a data-link-type="biblio" href="#biblio-p2161r2">[P2161R2]</a> (Remove Default Candidate Executor) to LWG for the
  Networking TS P-numbered Working Draft, classified as a focus work item
  (<a data-link-type="biblio" href="#biblio-p0592r4">[P0592R4]</a> bucket 1 item). 
      <td>6 
      <td>14 
      <td>2 
      <td>2 
      <td>0 
      <td>Consensus in favor. 
   </table>
   <h2 class="heading settled" data-level="3" id="summarized-outcomes"><span class="secno">3. </span><span class="content">Summarized Outcomes</span><a class="self-link" href="#summarized-outcomes"></a></h2>
   <p>Revise <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors) as follows and return to Library Evolution for
  further review:</p>
   <ul>
    <li data-md>
     <p>Apply <a data-link-type="biblio" href="#biblio-p2235r0">[P2235R0]</a>.</p>
    <li data-md>
     <p>Remove <code class="highlight"><c- n>static_thread_pool</c-></code>.
A separate follow-on proposal for <code class="highlight"><c- n>static_thread_pool</c-></code> is encouraged.</p>
    <li data-md>
     <p>Remove <code class="highlight"><c- n>any_executor</c-></code>.
If <code class="highlight"><c- n>any_executor</c-></code> is pursued in the future, <code class="highlight"><c- n>any_executor</c-><c- o>::</c-><c- n>target</c-></code> and <code class="highlight"><c- n>any_executor</c-><c- o>::</c-><c- n>target_type</c-></code> shall be removed.</p>
   </ul>
   <p>We will continue on our planned course of aiming to ship <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors) in C++23, but a notable minority in Library Evolution are not
  convinced that <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors) is sufficiently mature.
Library Evolution wants to see more field experience with <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors).
P0443R14 (Executors) authors and advocates should take note of this.
Focus on demonstrating field experience through implementations and usage,
  improving introductory material, minimizing the scope, resolving outstanding
  minor open issues, and developing wording to increase Library Evolution
  confidence in the maturity of <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors).</p>
   <p>We encourage a separate follow-on proposal exploring individual traits versus
  combined traits classes in general, using <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors) as an
  example to gauge impact.</p>
   <p><a data-link-type="biblio" href="#biblio-p2212r1">[P2212R1]</a> (Relax Requirements for <code class="highlight"><c- n>time_point</c-><c- o>::</c-><c- n>clock</c-></code>) is sent LWG for C++23,
  classified as an improvement of an existing feature (<a data-link-type="biblio" href="#biblio-p0592r4">[P0592R4]</a> bucket
  2 item).</p>
   <p><a data-link-type="biblio" href="#biblio-p2166r1">[P2166R1]</a> (Prohibit <code class="highlight"><c- n>basic_string</c-></code> and <code class="highlight"><c- n>basic_string_view</c-></code> Construction
  from <code class="highlight"><c- k>nullptr</c-></code>) is sent to LWG for C++23, classified as an improvement of an
  existing feature (<a data-link-type="biblio" href="#biblio-p0592r4">[P0592R4]</a> bucket 2 item).</p>
   <p><a data-link-type="biblio" href="#biblio-p2161r2">[P2161R2]</a> (Remove Default Candidate Executor) is sent to LWG for the
  Networking TS Working Draft, classified as a focus work item (<a data-link-type="biblio" href="#biblio-p0592r4">[P0592R4]</a> bucket 1 item).</p>
   <h2 class="heading settled" data-level="4" id="detailed-results"><span class="secno">4. </span><span class="content">Detailed Poll Results and Selected Comments</span><a class="self-link" href="#detailed-results"></a></h2>
   <h3 class="heading settled" data-level="4.1" id="executor-polls"><span class="secno">4.1. </span><span class="content">Executor Polls</span><a class="self-link" href="#executor-polls"></a></h3>
   <p>The following C++ Library Evolution polls relate to executors (<a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a>),
  a proposed set of abstractions for asynchronously creating and managing
  execution agents.</p>
   <h4 class="heading settled" data-level="4.1.1" id="poll-0"><span class="secno">4.1.1. </span><span class="content">Poll 0</span><a class="self-link" href="#poll-0"></a></h4>
   <p>Remove implicit adaptation from <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors) by applying <a data-link-type="biblio" href="#biblio-p2235r0">[P2235R0]</a> to <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a>) which will:</p>
   <ul>
    <li data-md>
     <p>Make <code class="highlight"><c- n>schedule</c-></code> only take <code class="highlight"><c- n>scheduler</c-></code>s.</p>
    <li data-md>
     <p>Make <code class="highlight"><c- n>execute</c-></code> only take <code class="highlight"><c- n>executor</c-></code>s.</p>
    <li data-md>
     <p>Make sender and receiver operations like <code class="highlight"><c- n>connect</c-></code> only take senders and
receivers.</p>
    <li data-md>
     <p>Add explicit adaptation from <code class="highlight"><c- n>executor</c-></code> to <code class="highlight"><c- n>scheduler</c-></code> (<code class="highlight"><c- n>make_scheduler_from_executor</c-></code>) but not vice versa.</p>
   </ul>
   <table>
    <tbody>
     <tr>
      <th>Strongly Favor 
      <th>Weakly Favor 
      <th>Neutral 
      <th>Weakly Against 
      <th>Strongly Against 
     <tr>
      <th>21 
      <th>15 
      <th>0 
      <th>0 
      <th>0 
   </table>
   <h5 class="no-toc heading settled" data-level="4.1.1.1" id="outcome"><span class="secno">4.1.1.1. </span><span class="content">Outcome</span><a class="self-link" href="#outcome"></a></h5>
   <p>Unanimous consensus in favor.
We will need to continue discussing explicit adaptation, the relationship
  between <code class="highlight"><c- n>scheduler</c-></code> and <code class="highlight"><c- n>executor</c-></code> and the implications of bifurcation on the
  ecosystem.</p>
   <h5 class="no-toc heading settled" data-level="4.1.1.2" id="selected-comments"><span class="secno">4.1.1.2. </span><span class="content">Selected Comments</span><a class="self-link" href="#selected-comments"></a></h5>
   <blockquote>
    <p>I feel unable to support moving this proposal forward since I still find it
  next to impossible to understand what’s going on, despite extensive
  discussion and leading a review group.</p>
    <p>— Did Not Vote</p>
   </blockquote>
   <blockquote>
    <p>[Implicit adaptation] adaption was the biggest issue with <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a>!</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a step in the right direction.
I think additional simplifications are possible and desirable, but I am happy
  with this direction.</p>
    <p>— Strongly Favor.</p>
   </blockquote>
   <blockquote>
    <p>The circularity between <code class="highlight"><c- n>execution</c-><c- o>::</c-><c- n>execute</c-></code> and <code class="highlight"><c- n>execution</c-><c- o>::</c-><c- n>connect</c-></code> is
  complicated and must be eliminated.
However, the resulting disconnection between <code class="highlight"><c- n>executor</c-></code>s and <code class="highlight"><c- n>scheduler</c-></code>s is
  a bug that must be addressed.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is fine, though it may result in some awkwardness when forming overloads
  that accept both a scheduler and an executor.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I think that the <a data-link-type="biblio" href="#biblio-p2235r0">[P2235R0]</a> suggestions are good overall.
Removing implicit adaptations should make things clearer.
Currently there are places where the behavior of customization points is not
  obvious due to all of those implicit adaptation features.
However, I still think that there are different opinions about which notion
  is the base one: <code class="highlight"><c- n>scheduler</c-></code> or <code class="highlight"><c- n>executor</c-></code>.
To me it’s <code class="highlight"><c- n>scheduler</c-></code>.
I believe we already discussed that fire-and-forget semantics can be
  implemented via schedulers.
On the other hand, executors don’t support chaining and error handling in a
  manner how schedulers do that.
That’s why schedulers look more fundamental IMO. I could easily imagine <code class="highlight"><c- n>make_executor_from_scheduler</c-></code> method that returns executor, which ignores
  error channel or terminates.
Overall: what I mean by my comment is the explicit adaptation functions set is
  still open question to me.
And I am raising which one is more fundamental because I see the possible
  implications to other part of C++ library (e.g. C++17 parallel algorithms).</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I approve of the simplification.
I disapprove of the resulting bifurcation.
There will be two async worlds - libraries that deal in executors and
  libraries that deal in schedulers.
The status quo required library authors to consider and support both - now
  authors will focus on one and ignore the other.
Given this change LEWG needs to decide which will survive and remove the
  other one.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <h4 class="heading settled" data-level="4.1.2" id="poll-1"><span class="secno">4.1.2. </span><span class="content">Poll 1</span><a class="self-link" href="#poll-1"></a></h4>
   <p>Use one class for each individual trait instead of combined traits classes
  (<code class="highlight"><c- n>sender_traits</c-></code>, etc) in <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors).</p>
   <table>
    <tbody>
     <tr>
      <th>Strongly Favor 
      <th>Weakly Favor 
      <th>Neutral 
      <th>Weakly Against 
      <th>Strongly Against 
     <tr>
      <th>7 
      <th>7 
      <th>7 
      <th>5 
      <th>2 
   </table>
   <h5 class="no-toc heading settled" data-level="4.1.2.1" id="outcome①"><span class="secno">4.1.2.1. </span><span class="content">Outcome</span><a class="self-link" href="#outcome①"></a></h5>
   <p>No consensus.
We encourage a separate follow-on proposal exploring individual traits versus
  combined traits classes in general, using <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors) as an
  example to gauge impact.</p>
   <h5 class="no-toc heading settled" data-level="4.1.2.2" id="selected-comments①"><span class="secno">4.1.2.2. </span><span class="content">Selected Comments</span><a class="self-link" href="#selected-comments①"></a></h5>
   <blockquote>
    <p>We’ve been moving towards single traits in general.
They are easier to specialize, and are more future-proof.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p><code class="highlight"><c- n>sender_traits</c-></code>' implementation is complicated.
Separate traits are easier to implement and use in metaprogramming.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Combined trait classes are often burdensome as extensive experience with <code class="highlight"><c- n>numeric_traits</c-></code> or especially <code class="highlight"><c- n>iterator_traits</c-></code> has shown.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I feel this is a preferable approach as it makes the traits more extensible
  and aligns with the precedent set by more recently introduced traits.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I think it’s worth thinking about using one class per trait, but I don’t think
  this should delay the proposal.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>Can live with both</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>I’m conflicted.
I like them grouped when they’re being used for their original intent.
It helps when learning about what needs to be defined.
If trying to reuse a trait for something else, then it can be unfortunate.
That case should probably define a specific trait for its own use.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>For associated types, current practice is for one trait per concept
  (<code class="highlight"><c- n>iterator_traits</c-></code>, <code class="highlight"><c- n>allocator_traits</c-></code>, <code class="highlight"><c- n>incrementable_traits</c-></code>, <code class="highlight"><c- n>readable_traits</c-></code>).
This also brings down total number of class template instantiations.
There are exceptions (<code class="highlight"><c- n>is_invocable</c-></code>, <code class="highlight"><c- n>invocable_result</c-></code>, etc.), so I am only
  mildly opposed.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>This provides the customiser with more ways to get an already complicated
  thing wrong</p>
    <p>— Strongly Against</p>
   </blockquote>
   <h4 class="heading settled" data-level="4.1.3" id="poll-2"><span class="secno">4.1.3. </span><span class="content">Poll 2</span><a class="self-link" href="#poll-2"></a></h4>
   <p>Remove <code class="highlight"><c- n>static_thread_pool</c-></code> from <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors).
It may be pursued in a follow-on proposal.</p>
   <table>
    <tbody>
     <tr>
      <th>Strongly Favor 
      <th>Weakly Favor 
      <th>Neutral 
      <th>Weakly Against 
      <th>Strongly Against 
     <tr>
      <th>8 
      <th>11 
      <th>4 
      <th>7 
      <th>2 
   </table>
   <h5 class="no-toc heading settled" data-level="4.1.3.1" id="outcome②"><span class="secno">4.1.3.1. </span><span class="content">Outcome</span><a class="self-link" href="#outcome②"></a></h5>
   <p>Weak consensus in favor.
Remove <code class="highlight"><c- n>static_thread_pool</c-></code> from <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors).
A separate follow-on proposal is encouraged as a number of people feel it is
  important.</p>
   <h5 class="no-toc heading settled" data-level="4.1.3.2" id="selected-comments②"><span class="secno">4.1.3.2. </span><span class="content">Selected Comments</span><a class="self-link" href="#selected-comments②"></a></h5>
   <blockquote>
    <p>No need to tie <code class="highlight"><c- n>static_thread_pool</c-></code> to executors, as the discussion is still
  ongoing and it isn’t a fundamental necessity.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p><a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> conflates too many things.
The thread pool is not fundamental to the concept of execution, and may not
  be the right default thread pool API for us to provide users anyway (a
  parallel forward progress system thread pool might be a better default).</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p><a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> does not define a concept for execution contexts like <code class="highlight"><c- n>static_thread_pool</c-></code>.
We are not ready to define the shape of an execution context - it is
  purely implementation defined for now.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p><code class="highlight"><c- n>static_thread_pool</c-></code> is niche but doesn’t look that way, especially if it’s
  the only execution resource provided in C++23.
We would be setting the community up to fail in the future when we
  standardize <code class="highlight"><c- n>system_executor</c-></code>.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>There needs to be some concrete execution context available at the time that
  executors/schedulers become available in the standard.
However because of the length/complexity of P0443, important sections, such as <code class="highlight"><c- n>static_thread_pool</c-></code>, can get lost in discussions.
For this reason, I think it would be better to isolate it in its own proposal
  so that it gets the full attention it requires.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>It’s still unclear to me how <code class="highlight"><c- n>static_thread_pool</c-></code> is problematic, but I’m
  not against it if it builds consensus.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>I don’t care for designs that are all framework, but no concrete
  implementation. <code class="highlight"><c- n>static_thread_pool</c-></code> seems useful in portable code, and it doesn’t seem
  terribly onerous to specify or implement.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>I feel it is important to have an initial thread pool executor available
  with executors when they are first introduced to C++ as it is a feature
  high in demand and provides the first standardized execution context,
  setting the convention for the execution context - executor relationship,
  so I would prefer the <code class="highlight"><c- n>static_thread_pool</c-></code> to remain in <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a>.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>The <code class="highlight"><c- n>static_thread_pool</c-></code> functionality is simple, succinct, mature, and
  satisfies a very common use case.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <h4 class="heading settled" data-level="4.1.4" id="poll-3"><span class="secno">4.1.4. </span><span class="content">Poll 3</span><a class="self-link" href="#poll-3"></a></h4>
   <p>Remove <code class="highlight"><c- n>any_executor</c-></code> from <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors).
It may be pursued in a follow-on proposal.</p>
   <table>
    <tbody>
     <tr>
      <th>Strongly Favor 
      <th>Weakly Favor 
      <th>Neutral 
      <th>Weakly Against 
      <th>Strongly Against 
     <tr>
      <th>10 
      <th>9 
      <th>4 
      <th>4 
      <th>2 
   </table>
   <h5 class="no-toc heading settled" data-level="4.1.4.1" id="outcome③"><span class="secno">4.1.4.1. </span><span class="content">Outcome</span><a class="self-link" href="#outcome③"></a></h5>
   <p>Consensus in favor.
Remove <code class="highlight"><c- n>any_executor</c-></code> from <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors).
If advocates for <code class="highlight"><c- n>any_executor</c-></code> still wish to pursue it, they should bring a
  separate proposal which contains detailed motivation and discussion of the
  ABI impacts and risks of <code class="highlight"><c- n>any_executor</c-></code>.</p>
   <h5 class="no-toc heading settled" data-level="4.1.4.2" id="selected-comments③"><span class="secno">4.1.4.2. </span><span class="content">Selected Comments</span><a class="self-link" href="#selected-comments③"></a></h5>
   <blockquote>
    <p>There are too many open questions about whether wrapping just any executor or
  more broadly using reference wrappers.
It also added a lot of questions where we seem to be defining mechanisms
  purely to support this type, yet it is not fundamental to the execution
  concepts <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> should be focused on.
It is important we have such a thing, but it should build on what is in <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> rather than driving it.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Separating any_executor from <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> will allow it to make progress
  faster.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p><code class="highlight"><c- n>any_executor</c-></code> is complicated enough that keeping it in <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> would slow
  things down.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p><code class="highlight"><c- n>any_executor</c-></code> has long complicated many aspects of the design of executors,
  properties in particular.
While I understand and sympathize with the use case, I don’t view this as
  essential to executors and would be willing to ship a standard without <code class="highlight"><c- n>any_executor</c-></code>.
We don’t need a type erasure mechanism for everything in the standard.
There are many facilities in the standard library, such as iterators and
  ranges, which could have a type erasure mechanism, but do not.
Additionally, standardizing type erasure facilities almost always leads to
  ABI issues down the road. Once we ship an <code class="highlight"><c- n>any_executor</c-></code>, it will be much
  harder to modify and fix problems in both executors and properties down the
  line.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Shipping it with executors will lock us into an ABI and I am very VERY much
  against that.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>My main concern is ABI.
If we get a proposal that adds a version field or something similar to it so
  that we can improve <code class="highlight"><c- n>any_executor</c-></code> in the future, then I would be fine
  leaving it in the main paper.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I think if it’s possible to make the things separated they probably should be
  split.
It allows them to move in parallel without stopping each other.
Furthermore, the Executors unified proposal looks too big.
If we can make it simpler to read and to understand, let’s do that.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>There is enough disagreement around <code class="highlight"><c- n>any_executor</c-></code> that it should be a
  separate proposal.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>The erasure for the concepts are hard to specify and review, and I believe
  this should be pursued with paper that presents concrete use case
  (Networking TS).</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I’ve always been neutral on whether or not executors should contain a type
  erasure mechanism from the start, but others were so strongly opinionated
  in the past that we added it.
I’m in favor of whatever builds the most consensus.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>I don’t know what type I’m supposed to use for non-generic code if this
  facility is removed.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>I believe that the polymorphic wrapper is a major use case for a number of
  applications and it should go together with the base specification.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p><code class="highlight"><c- n>any_executor</c-></code> is a convenient base for implementing polymorphic executors
  where two domains must intercommunicate.
Furthermore, this would impact negatively on the Networking TS as IO objects
  would be required to know their executor types.
This negatively affects: 1. code reuse with coroutines, and 2. compile times.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <blockquote>
    <p>A polymorphic executor is on the critical path for networking + <a data-link-type="biblio" href="#biblio-p1322r2">[P1322R2]</a>.
Deferring the choice of target executor until runtime is an extremely common
  requirement.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <h4 class="heading settled" data-level="4.1.5" id="poll-4"><span class="secno">4.1.5. </span><span class="content">Poll 4</span><a class="self-link" href="#poll-4"></a></h4>
   <p>Remove <code class="highlight"><c- n>any_executor</c-><c- o>::</c-><c- n>target</c-></code> and <code class="highlight"><c- n>any_executor</c-><c- o>::</c-><c- n>target_type</c-></code> from <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors).</p>
   <table>
    <tbody>
     <tr>
      <th>Strongly Favor 
      <th>Weakly Favor 
      <th>Neutral 
      <th>Weakly Against 
      <th>Strongly Against 
     <tr>
      <th>12 
      <th>10 
      <th>4 
      <th>2 
      <th>0 
   </table>
   <h5 class="no-toc heading settled" data-level="4.1.5.1" id="outcome④"><span class="secno">4.1.5.1. </span><span class="content">Outcome</span><a class="self-link" href="#outcome④"></a></h5>
   <p>Consensus in favor.
We have decided to remove <code class="highlight"><c- n>any_executor</c-></code> will be removed from <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a>, but if
  it is pursued in another proposal, <code class="highlight"><c- n>any_executor</c-><c- o>::</c-><c- n>target</c-></code> and <code class="highlight"><c- n>any_executor</c-><c- o>::</c-><c- n>target_type</c-></code> shall be removed.</p>
   <h5 class="no-toc heading settled" data-level="4.1.5.2" id="selected-comments④"><span class="secno">4.1.5.2. </span><span class="content">Selected Comments</span><a class="self-link" href="#selected-comments④"></a></h5>
   <blockquote>
    <p>These methods come with an unavoidable overhead which we should not impose on
  users.
If you need this functionality, it has been demonstrated that you can achieve
  it using properties. Adding <code class="highlight"><c- n>target</c-></code> and <code class="highlight"><c- n>target_type</c-></code> to <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>function</c-></code> was a mistake that we should not repeat. Removing these methods is
  consistent with other similar facilities that are in flight (<code class="highlight"><c- n>any_invocable</c-></code> and <code class="highlight"><c- n>function_ref</c-></code>).</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Including them breaks "don’t pay for what you don’t use" by forcing RTTI to be
  generated and stored in any_executor even if never called, and it’s possible
  to replicate the semantics removed here with properties.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>The functionality that relies on this in the Networking TS can be
  re-implemented in another way.
The current interface defeats the purpose of polymorphism by asking
  "what are you?", rather than the pertinent question of "can you fulfill my
  requirements?"</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>I believe that <code class="highlight"><c- n>any_executor</c-><c- o>::</c-><c- n>target</c-></code> has utility and have used it in
  production code. <code class="highlight"><c- n>any_executor</c-><c- o>::</c-><c- n>target_type</c-></code> less so and seems to be the point of contention
  due to RAII overhead.
Given that these removals were coupled in the poll question I have to vote
  against although I would be weakly in favor of removing <code class="highlight"><c- n>any_executor</c-><c- o>::</c-><c- n>target_type</c-></code>.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <h4 class="heading settled" data-level="4.1.6" id="poll-5"><span class="secno">4.1.6. </span><span class="content">Poll 5</span><a class="self-link" href="#poll-5"></a></h4>
   <p><a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors) is sufficiently mature that we should aim to ship
  it in C++23.</p>
   <table>
    <tbody>
     <tr>
      <th>Strongly Favor 
      <th>Weakly Favor 
      <th>Neutral 
      <th>Weakly Against 
      <th>Strongly Against 
     <tr>
      <th>10 
      <th>12 
      <th>7 
      <th>10 
      <th>1 
   </table>
   <h5 class="no-toc heading settled" data-level="4.1.6.1" id="outcome⑤"><span class="secno">4.1.6.1. </span><span class="content">Outcome</span><a class="self-link" href="#outcome⑤"></a></h5>
   <p>Weak consensus in favor.
We will continue on our planned course of aiming to ship <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors) in C++23, but a notable minority in Library Evolution are not
  convinced that <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors) is sufficiently mature.
Library Evolution wants to see more field experience with <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors). <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors) authors and advocates should take note of this.
Focus on demonstrating field experience through implementations and usage,
  improving introductory material, minimizing the scope, resolving outstanding
  minor open issues, and developing wording to increase Library Evolution
  confidence in the maturity of <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> (Executors).</p>
   <h5 class="no-toc heading settled" data-level="4.1.6.2" id="selected-comments⑤"><span class="secno">4.1.6.2. </span><span class="content">Selected Comments</span><a class="self-link" href="#selected-comments⑤"></a></h5>
   <blockquote>
    <p>The executors design that is in <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> is the result of a long period of
  hard work and compromise from a large number of authors from various
  different domains and I feel that it has now settled into a very stable
  state that well represents the various use cases identified and there has
  been enough implementation experience that I am confident in the design.
I feel that there are still aspects which may need further iteration but a
  great many alternative approaches have been exhausted in the route to where
  we are now and I don’t believe that the core design should change
  significantly.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Executors has made a lot of progress over the years and I believe we are on
  track to ship it in C++23. Assuming that we adopt <a data-link-type="biblio" href="#biblio-p2235r0">[P2235R0]</a> (Disentangling
  Schedulers and Executors), the proposal becomes a lot simpler, and I think
  once the dust settles from that and other proposed simplifications we will
  have a solid core proposal.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>While I have some concerns about Executors, and there is a chance it may not
  be ready, I do not believe at this point we should derail this car from
  the train.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>We should certainly (continue to) aim to ship it in C++23.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>The executors design discussion has been going on for a long time.
It has matured to the point where I think it’s important to focus our efforts
  on shipping it.
Focusing on making design decisions that move us closer to shipping in the
  IS is valuable at this point.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Executors (+schedulers, sender, receiver) are basic building blocks of so many
  library proposals we MUST aim to ship them in C++23 after missing C++20.
It hampers the overall evolution of C++.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I think P0443 is mature enough that we should continue with the goal of
  landing in C++23.
There is a risk that we will work on <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a>, but not make C++23, and
  some other features will miss C++23 because of the time spent on P0443.
But I think the benefit of getting executors into C++23 is big enough and the
  chance of success high enough that it is worth taking that risk.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>The recent discussions indicate that, while significant tweaks are justified,
  the basic design is sound, and prioritizing its (cleanup and) adoption is
  necessary to meaningfully consider other proposals in flight.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Ideally, I would prefer more usage experience.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>I think this still has a chance, but it will be tough.
I am particularly concerned about getting the wording into a useful state in
  time for LWG to get through the paper.
It is a bit disheartening to think that it’s already "late" into C++23 design
  when we just released C++20 in February.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>Significant aspects of the design seem to be still in flux, and the paper
  doesn’t report implementation/usage experience for the combined facility
  (even though parts of it have been implemented in different libraries).
This seems less than optimal for something as fundamental as executors.</p>
    <p>— Neutral</p>
   </blockquote>
   <blockquote>
    <p>I feel unable to support moving this proposal forward since I still find it
  next to impossible to understand what’s going on, despite extensive
  discussion and leading a review group.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>I don’t know that the committee fully understands the whole proposal.
I don’t know that the authors' implementation experience is sufficiently
  diverse.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>There are too many things blocked on executors not to try to ship it as soon
  as possible.
The addition of senders and receivers is essential.
The use of properties -- which need for which has never been satisfactorily
  explained -- smells like an immature element.
If properties were replaced with <code class="highlight"><c- n>tag_invoke</c-></code> CPOs would change me to strongly
  favor.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>I strongly want executors to make progress towards standardization; however, I
  am concerned by the number of fundamental changes that have been proposed
  recently.
For example <a data-link-type="biblio" href="#biblio-p2235r0">[P2235R0]</a> proposes a design change that completely separates
  executors / schedulers.
There have also been discussions in the last month about whether properties
  (a large part of <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a>) are the right abstraction.
There is also disagreement in SG1 [on whether] algorithms will receive
  executors or schedulers as arguments.
It seems premature to standardize executors/schedulers without knowing what
  the <code class="highlight"><c- n>std</c-></code> algorithms will actually use.
There is also very little, if any, practical experience with what is
  specifically proposed in <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a>.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <h3 class="heading settled" data-level="4.2" id="other-polls"><span class="secno">4.2. </span><span class="content">Other Polls</span><a class="self-link" href="#other-polls"></a></h3>
   <h4 class="heading settled" data-level="4.2.1" id="poll-6"><span class="secno">4.2.1. </span><span class="content">Poll 6</span><a class="self-link" href="#poll-6"></a></h4>
   <p>Send <a data-link-type="biblio" href="#biblio-p2212r1">[P2212R1]</a> (Relax Requirements for <code class="highlight"><c- n>time_point</c-><c- o>::</c-><c- n>clock</c-></code>) to LWG for C++23,
  classified as an improvement of an existing feature (<a data-link-type="biblio" href="#biblio-p0592r4">[P0592R4]</a> bucket
  2 item).</p>
   <table>
    <tbody>
     <tr>
      <th>Strongly Favor 
      <th>Weakly Favor 
      <th>Neutral 
      <th>Weakly Against 
      <th>Strongly Against 
     <tr>
      <th>18 
      <th>13 
      <th>3 
      <th>0 
      <th>0 
   </table>
   <h5 class="no-toc heading settled" data-level="4.2.1.1" id="outcome⑥"><span class="secno">4.2.1.1. </span><span class="content">Outcome</span><a class="self-link" href="#outcome⑥"></a></h5>
   <p>Strong consensus in favor.</p>
   <h5 class="no-toc heading settled" data-level="4.2.1.2" id="selected-comments⑥"><span class="secno">4.2.1.2. </span><span class="content">Selected Comments</span><a class="self-link" href="#selected-comments⑥"></a></h5>
   <blockquote>
    <p>This is a very small fix which relaxes an unnecessary requirement to support
  additional valid use cases.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is a great step towards stateful clocks that are required for simulation
  and testing faster-than-real-time.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <h4 class="heading settled" data-level="4.2.2" id="poll-7"><span class="secno">4.2.2. </span><span class="content">Poll 7</span><a class="self-link" href="#poll-7"></a></h4>
   <p>Send <a data-link-type="biblio" href="#biblio-p2166r1">[P2166R1]</a> (Prohibit <code class="highlight"><c- n>basic_string</c-></code> and <code class="highlight"><c- n>basic_string_view</c-></code> Construction
  from <code class="highlight"><c- k>nullptr</c-></code>) to LWG for C++23, classified as an improvement of an
  existing feature (<a data-link-type="biblio" href="#biblio-p0592r4">[P0592R4]</a> bucket 2 item).</p>
   <table>
    <tbody>
     <tr>
      <th>Strongly Favor 
      <th>Weakly Favor 
      <th>Neutral 
      <th>Weakly Against 
      <th>Strongly Against 
     <tr>
      <th>15 
      <th>18 
      <th>2 
      <th>2 
      <th>1 
   </table>
   <h5 class="no-toc heading settled" data-level="4.2.2.1" id="outcome⑦"><span class="secno">4.2.2.1. </span><span class="content">Outcome</span><a class="self-link" href="#outcome⑦"></a></h5>
   <p>Consensus in favor.</p>
   <h5 class="no-toc heading settled" data-level="4.2.2.2" id="selected-comments⑦"><span class="secno">4.2.2.2. </span><span class="content">Selected Comments</span><a class="self-link" href="#selected-comments⑦"></a></h5>
   <blockquote>
    <p>This adds a very valuable protection against common errors and makes <code class="highlight"><c- n>string_view</c-></code> more "self-documenting".
The counter-argument that this precludes an eventual permission to allow <code class="highlight"><c- n>string_view</c-></code> to be constructed from a single null pointer argument seems
  entirely unhelpful, since such an extension itself would be a poor and
  unfortunate direction to take (as has been amply discussed, and as was in
  fact subject of an overwhelmingly clear straw poll).</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>There is enough benefit to this proposal in preventing bugs that we ought to
  do it, even though the same bug at runtime may not be caught.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>We’ve discussed this topic many times.
We can’t fix all the potential footguns, but this covers a decent set of them,
  so I’m in favor of it.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>This is only a partial solution to the problem of creating a string from a
  null pointer, and the proposed solution has complications.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>I was doubting about Weakly Against and Strongly Against.
But chose the latter.
Yes, this proposal is very easy to implement but it’s doesn’t bring much value
  to me.
It covers very small subset of use-cases.
As the paper says it doesn’t help if the <code class="highlight"><c- n>pointer</c-> <c- n>p</c-> <c- o>=</c-> <c- k>nullptr</c-></code> and then we
  construct <code class="highlight"><c- n>string</c-><c- p>(</c-><c- n>p</c-><c- p>)</c-></code> and I understand that we cannot do anything useful
  here at compile-time.
What I mean (and the paper explicitly says that) the previous use-case still
  requires run-time check.
Furthermore, the proposal doesn’t look deeply elaborated.
It doesn’t answer the questions what happens if we construct <code class="highlight"><c- n>string</c-><c- p>(</c->NULL<c- p>)</c-></code> or <code class="highlight"><c- n>string</c-><c- p>(</c-><c- mi>0</c-><c- p>)</c-></code>.
With that proposal I am guessing it would cause ambiguity and probably it’s
  better than run-time failure but still doesn’t look very obvious to the
  user.
I would like to see other design considerations.
For example why don’t just mark some templatized constructor as <code class="highlight"><c- o>=</c-> <c- k>delete</c-></code>?
I am not saying this is the good solution because it’s just taken from the top
  of my head.
But it seems it can cover more use-cases with <code class="highlight"><c- k>nullptr</c-></code>, <code class="highlight"><c- mi>0</c-></code>, <code class="highlight">NULL</code> and
  potentially others, which looks better to me.
Anyway, other possible solutions should be elaborated and described in the
  paper.
Overall, I think that this proposal needs more work to be done.
If the solution for broader number of use-cases wouldn’t be found I would not
  ship this proposal just for the sake of <code class="highlight"><c- k>nullptr</c-></code> use-case.
Currently, I would prefer having some run-time checks (e.g. assert) in the
  debug version of C++ standard library implementations rather then current
  state of the art of <a data-link-type="biblio" href="#biblio-p2166r1">[P2166R1]</a>.</p>
    <p>— Strongly Against</p>
   </blockquote>
   <h4 class="heading settled" data-level="4.2.3" id="poll-8"><span class="secno">4.2.3. </span><span class="content">Poll 8</span><a class="self-link" href="#poll-8"></a></h4>
   <p>Send <a data-link-type="biblio" href="#biblio-p2161r2">[P2161R2]</a> (Remove Default Candidate Executor) to LWG for the Networking
  TS Working Draft, classified as a focus work item (<a data-link-type="biblio" href="#biblio-p0592r4">[P0592R4]</a> bucket 1 item).</p>
   <table>
    <tbody>
     <tr>
      <th>Strongly Favor 
      <th>Weakly Favor 
      <th>Neutral 
      <th>Weakly Against 
      <th>Strongly Against 
     <tr>
      <th>6 
      <th>14 
      <th>2 
      <th>2 
      <th>0 
   </table>
   <h5 class="no-toc heading settled" data-level="4.2.3.1" id="outcome⑧"><span class="secno">4.2.3.1. </span><span class="content">Outcome</span><a class="self-link" href="#outcome⑧"></a></h5>
   <p>Consensus in favor.</p>
   <h5 class="no-toc heading settled" data-level="4.2.3.2" id="selected-comments⑧"><span class="secno">4.2.3.2. </span><span class="content">Selected Comments</span><a class="self-link" href="#selected-comments⑧"></a></h5>
   <blockquote>
    <p>The current default executor, <code class="highlight"><c- n>system_executor</c-></code> makes races to completion
  implicit in the design and should absolutely not be the default.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>This makes it much more difficult to accidentally run afoul of UB when
  writing networking code.
No behavior is lost you just have to opt into the behavior which is always
  good if the behavior is potentially dangerous.</p>
    <p>— Strongly Favor</p>
   </blockquote>
   <blockquote>
    <p>Executors (in either the Networking TS or in the SG1 incarnation) are meant
  to provide better control for siting work; making it easy to not exercise
  such control is not very important and may silently harm performance
  portability.</p>
    <p>— Weakly Favor</p>
   </blockquote>
   <blockquote>
    <p>Since the executor design and its eventual integration with networking is
  still in flux, and we do not plan to ship a networking TS v2, forwarding
  this as a standalone paper at the highest priority seems to be a poor use
  of limited LWG time. It should be folded into some "integrating executors
  and networking" paper once the executor design is settled.</p>
    <p>— Weakly Against</p>
   </blockquote>
   <blockquote>
    <p>I think a platform-specific default is useful.</p>
    <p>— Weakly Against</p>
   </blockquote>
  </main>
<script>
(function() {
  "use strict";
  var collapseSidebarText = '<span aria-hidden="true">←</span> '
                          + '<span>Collapse Sidebar</span>';
  var expandSidebarText   = '<span aria-hidden="true">→</span> '
                          + '<span>Pop Out Sidebar</span>';
  var tocJumpText         = '<span aria-hidden="true">↑</span> '
                          + '<span>Jump to Table of Contents</span>';

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

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

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

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

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

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


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

    tocNav.appendChild(toggle);
  }

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

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

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

})();
</script>
  <h2 class="no-num no-ref heading settled" id="references"><span class="content">References</span><a class="self-link" href="#references"></a></h2>
  <h3 class="no-num no-ref heading settled" id="informative"><span class="content">Informative References</span><a class="self-link" href="#informative"></a></h3>
  <dl>
   <dt id="biblio-p0443r14">[P0443R14]
   <dd>Jared Hoberock, Michael Garland, Chris Kohlhoff, Chris Mysen, H. Carter Edwards, Gordon Brown, D. S. Hollman. <a href="https://wg21.link/p0443r14">A Unified Executors Proposal for C++</a>. 15 September 2020. URL: <a href="https://wg21.link/p0443r14">https://wg21.link/p0443r14</a>
   <dt id="biblio-p0592r4">[P0592R4]
   <dd>Ville Voutilainen. <a href="https://wg21.link/p0592r4">To boldly suggest an overall plan for C++23</a>. 25 November 2019. URL: <a href="https://wg21.link/p0592r4">https://wg21.link/p0592r4</a>
   <dt id="biblio-p1322r2">[P1322R2]
   <dd>Christopher Kohlhoff. <a href="https://wg21.link/p1322r2">Networking TS enhancement to enable custom I/O executors</a>. 21 August 2020. URL: <a href="https://wg21.link/p1322r2">https://wg21.link/p1322r2</a>
   <dt id="biblio-p2161r2">[P2161R2]
   <dd>Robert Leahy. <a href="https://wg21.link/p2161r2">Remove Default Candidate Executor</a>. 14 July 2020. URL: <a href="https://wg21.link/p2161r2">https://wg21.link/p2161r2</a>
   <dt id="biblio-p2166r1">[P2166R1]
   <dd>Yuriy Chernyshov. <a href="https://wg21.link/p2166r1">A Proposal to Prohibit std::basic_string and std::basic_string_view construction from nullptr</a>. 7 September 2020. URL: <a href="https://wg21.link/p2166r1">https://wg21.link/p2166r1</a>
   <dt id="biblio-p2212r1">[P2212R1]
   <dd>Alexey Dmitriev, Howard Hinnant. <a href="https://wg21.link/p2212r1">Relax Requirements for time_point::clock</a>. 14 September 2020. URL: <a href="https://wg21.link/p2212r1">https://wg21.link/p2212r1</a>
   <dt id="biblio-p2233r3">[P2233R3]
   <dd>Bryce Adelstein Lelbach. <a href="https://isocpp.org/files/papers/P2233R3.html">2020 Fall Library Evolution Polls</a>. 23 November 2020. URL: <a href="https://isocpp.org/files/papers/P2233R3.html">https://isocpp.org/files/papers/P2233R3.html</a>
   <dt id="biblio-p2235r0">[P2235R0]
   <dd>Ville Voutilainen. <a href="https://wg21.link/p2235r0">Disentangling schedulers and executors</a>. 15 October 2020. URL: <a href="https://wg21.link/p2235r0">https://wg21.link/p2235r0</a>
  </dl>