<!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>P1018R8: C++ Language Evolution status 🦠 pandemic edition 🦠 2020/11–2021/01</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
 *
 * 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)
 *   - .assertion  for assertions                    (div, p, span)
 *   - .advisement for loud normative statements     (div, p, strong)
 *   - .annoying-warning for spec obsoletion notices (div, aside, details)
 *
 * 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
 *
 * 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 {
		color: black;
		color: var(--text);
		background-color: white;
		background-color: var(--bg);
	}

	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;

		background: transparent 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: 2;
			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: medium;
	}
	dfn var {
		font-style: normal;
	}

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

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

/** 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 {
		padding: .5em;
		border: .5em;
		border-left-style: solid;
		page-break-inside: avoid;
	}
	span.issue, span.note {
		padding: .1em .5em .15em;
		border-right-style: solid;
	}

	.issue,
	.note,
	.example,
	.advisement,
	.assertion,
	blockquote {
		margin: 1em auto;
	}
	.note  > p:first-child,
	.issue > p:first-child,
	blockquote > :first-child {
		margin-top: 0;
	}
	blockquote > :last-child {
		margin-bottom: 0;
	}


	.issue::before, .issue > .marker,
	.example::before, .example > .marker,
	.note::before, .note > .marker,
	details.note > 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);
	}

/** 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;
		line-height: 1.1rem; /* consistent spacing */
	}

	/* 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 .secno { font-size: 85%; }
	.toc > li li li li li { font-size:   85%;    }
	.toc > li li li li li .secno { font-size: 100%; }

	/* @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 {
			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;
	}

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

	@media print {
		/* Pages have their own margins. */
		html {
			margin: 0;
		}
		/* Serif for print. */
		body {
			font-family: serif;
		}
	}
	@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 table positioning:
		   "content column" is 50ems wide at max; less on smaller screens.
		   Extra space (after ToC + content) is empty on the right.

		   1. When table < content column, centers table in column.
		   2. When content < table < available, left-aligns.
		   3. When table > 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 89ebb6ab, updated Fri Oct 9 15:32:07 2020 -0700" name="generator">
  <link href="http://wg21.link/P1018r8" rel="canonical">
  <link href="https://isocpp.org/favicon.ico" rel="icon">
  <meta content="be5fa1ca69bd949952b4b0d217517b03d490154e" name="document-revision">
<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 */
html {
    color: black;
    color: var(--text);
    background-color: white;
    background-color: var(--bg);
}
:root {
    color-scheme: light dark;

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

    --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);

    --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-syntax-highlighting */

code.highlight { padding: .1em; border-radius: .3em; }
pre.highlight, pre > code.highlight { display: block; padding: 1em; margin: .5em 0; overflow: auto; border-radius: 0; }

.highlight:not(.idl) { background: #fdf6e3; }
c-[a] { color: #990055 } /* Keyword.Declaration */
c-[b] { color: #990055 } /* Keyword.Type */
c-[c] { color: #708090 } /* Comment */
c-[d] { color: #708090 } /* Comment.Multiline */
c-[e] { color: #0077aa } /* Name.Attribute */
c-[f] { color: #669900 } /* Name.Tag */
c-[g] { color: #222222 } /* Name.Variable */
c-[k] { color: #990055 } /* Keyword */
c-[l] { color: #000000 } /* Literal */
c-[m] { color: #000000 } /* Literal.Number */
c-[n] { color: #0077aa } /* Name */
c-[o] { color: #999999 } /* Operator */
c-[p] { color: #999999 } /* Punctuation */
c-[s] { color: #a67f59 } /* Literal.String */
c-[t] { color: #a67f59 } /* Literal.String.Single */
c-[u] { color: #a67f59 } /* Literal.String.Double */
c-[cp] { color: #708090 } /* Comment.Preproc */
c-[c1] { color: #708090 } /* Comment.Single */
c-[cs] { color: #708090 } /* Comment.Special */
c-[kc] { color: #990055 } /* Keyword.Constant */
c-[kn] { color: #990055 } /* Keyword.Namespace */
c-[kp] { color: #990055 } /* Keyword.Pseudo */
c-[kr] { color: #990055 } /* Keyword.Reserved */
c-[ld] { color: #000000 } /* Literal.Date */
c-[nc] { color: #0077aa } /* Name.Class */
c-[no] { color: #0077aa } /* Name.Constant */
c-[nd] { color: #0077aa } /* Name.Decorator */
c-[ni] { color: #0077aa } /* Name.Entity */
c-[ne] { color: #0077aa } /* Name.Exception */
c-[nf] { color: #0077aa } /* Name.Function */
c-[nl] { color: #0077aa } /* Name.Label */
c-[nn] { color: #0077aa } /* Name.Namespace */
c-[py] { color: #0077aa } /* Name.Property */
c-[ow] { color: #999999 } /* Operator.Word */
c-[mb] { color: #000000 } /* Literal.Number.Bin */
c-[mf] { color: #000000 } /* Literal.Number.Float */
c-[mh] { color: #000000 } /* Literal.Number.Hex */
c-[mi] { color: #000000 } /* Literal.Number.Integer */
c-[mo] { color: #000000 } /* Literal.Number.Oct */
c-[sb] { color: #a67f59 } /* Literal.String.Backtick */
c-[sc] { color: #a67f59 } /* Literal.String.Char */
c-[sd] { color: #a67f59 } /* Literal.String.Doc */
c-[se] { color: #a67f59 } /* Literal.String.Escape */
c-[sh] { color: #a67f59 } /* Literal.String.Heredoc */
c-[si] { color: #a67f59 } /* Literal.String.Interpol */
c-[sx] { color: #a67f59 } /* Literal.String.Other */
c-[sr] { color: #a67f59 } /* Literal.String.Regex */
c-[ss] { color: #a67f59 } /* Literal.String.Symbol */
c-[vc] { color: #0077aa } /* Name.Variable.Class */
c-[vg] { color: #0077aa } /* Name.Variable.Global */
c-[vi] { color: #0077aa } /* Name.Variable.Instance */
c-[il] { color: #000000 } /* Literal.Number.Integer.Long */
</style>
<style>/* style-darkmode */

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

        --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);

        --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">P1018R8<br>C++ Language Evolution status 🦠 pandemic edition 🦠 2020/11–2021/01</h1>
   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Published Proposal, <time class="dt-updated" datetime="2021-01-27">2021-01-27</time></span></h2>
   <div data-fill-with="spec-metadata">
    <dl>
     <dt>This version:
     <dd><a class="u-url" href="http://wg21.link/P1018r8">http://wg21.link/P1018r8</a>
     <dt class="editor">Author:
     <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:cxx@jfbastien.com">JF Bastien</a> (<span class="p-org org">Woven Planet</span>)
     <dt>Audience:
     <dd>WG21, EWG
     <dt>Project:
     <dd>ISO/IEC JTC1/SC22/WG21 14882: Programming Language — C++
     <dt>Source:
     <dd><a href="https://github.com/jfbastien/papers/blob/master/source/P1018r8.bs">github.com/jfbastien/papers/blob/master/source/P1018r8.bs</a>
    </dl>
   </div>
   <div data-fill-with="warning"></div>
   <hr title="Separator for header">
  </div>
  <div class="p-summary" data-fill-with="abstract">
   <h2 class="no-num no-toc no-ref heading settled" id="abstract"><span class="content">Abstract</span></h2>
   <p>This paper is a collection of items that the C++ Language Evolution group has worked on in the latest meeting, their status, and plans for the future.</p>
  </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="#summary"><span class="secno">1</span> <span class="content">Executive summary</span></a>
    <li><a href="#note"><span class="secno">2</span> <span class="content">Paper of note</span></a>
    <li><a href="#tentative"><span class="secno">3</span> <span class="content">Tentatively ready papers</span></a>
    <li><a href="#issue-pro"><span class="secno">4</span> <span class="content">Issue Processing</span></a>
    <li>
     <a href="#polls"><span class="secno">5</span> <span class="content">Polls</span></a>
     <ol class="toc">
      <li><a href="#P2223R1"><span class="secno">5.1</span> <span class="content">P2223R1 Trimming whitespaces before line splicing</span></a>
      <li><a href="#P2201R0"><span class="secno">5.2</span> <span class="content">P2201R0 Mixed string literal concatenation</span></a>
      <li><a href="#P2186R1"><span class="secno">5.3</span> <span class="content">P2186R1 Removing Garbage Collection Support</span></a>
      <li><a href="#P2173R0"><span class="secno">5.4</span> <span class="content">P2173R0 Attributes on Lambda-Expressions</span></a>
      <li><a href="#P2156R1"><span class="secno">5.5</span> <span class="content">P2156R1 Allow Duplicate Attributes</span></a>
      <li><a href="#P2013R3"><span class="secno">5.6</span> <span class="content">P2013R3 Freestanding Language: Optional <code class="highlight"><c- o>::</c-><c- k>operator</c-> <c- k>new</c-></code></span></a>
      <li><a href="#P1949R6"><span class="secno">5.7</span> <span class="content">P1949R6 C++ Identifier Syntax using Unicode Standard Annex 31</span></a>
      <li><a href="#P1938R2"><span class="secno">5.8</span> <span class="content">P1938R2 <code class="highlight"><c- k>if</c-> <c- k>consteval</c-></code></span></a>
      <li><a href="#P1847R3"><span class="secno">5.9</span> <span class="content">P1847R3 Make declaration order layout mandated</span></a>
      <li><a href="#P1401R4"><span class="secno">5.10</span> <span class="content">P1401R4 Narrowing contextual conversions to <code class="highlight"><c- b>bool</c-></code></span></a>
      <li><a href="#P1393R0"><span class="secno">5.11</span> <span class="content">P1393R0 A General Property Customization Mechanism</span></a>
      <li><a href="#CWG2169"><span class="secno">5.12</span> <span class="content">CWG2169 Narrowing conversions and overload resolution</span></a>
      <li><a href="#CWG2355"><span class="secno">5.13</span> <span class="content">CWG2355 Deducing <i>noexcept-specifiers</i></span></a>
      <li><a href="#CWG476"><span class="secno">5.14</span> <span class="content">CWG476 Determining the buffer size for placement <code class="highlight"><c- k>new</c-></code></span></a>
      <li><a href="#CWG687"><span class="secno">5.15</span> <span class="content">CWG687 <code class="highlight"><c- k>template</c-></code> keyword with <i>unqualified-id</i>s</span></a>
      <li><a href="#CWG1326"><span class="secno">5.16</span> <span class="content">CWG1326 Deducing an array bound from an <i>initializer-list</i></span></a>
      <li><a href="#CWG1331"><span class="secno">5.17</span> <span class="content">CWG1331 <code class="highlight"><c- k>const</c-></code> mismatch with defaulted copy constructor</span></a>
      <li><a href="#CWG1393"><span class="secno">5.18</span> <span class="content">CWG1393 Pack expansions in <i>using-declaration</i>s</span></a>
      <li><a href="#CWG1426"><span class="secno">5.19</span> <span class="content">CWG1426 Allowing additional parameter types in defaulted functions</span></a>
      <li><a href="#CWG1561"><span class="secno">5.20</span> <span class="content">CWG1561 Aggregates with empty base classes</span></a>
      <li><a href="#CWG1912"><span class="secno">5.21</span> <span class="content">CWG1912 <i>exception-specification</i> of defaulted function</span></a>
      <li><a href="#CWG1931"><span class="secno">5.22</span> <span class="content">CWG1931 Default-constructible and copy-assignable closure types</span></a>
      <li><a href="#CWG2295"><span class="secno">5.23</span> <span class="content">CWG2295 Aggregates with deleted defaulted constructors</span></a>
      <li><a href="#CWG2341"><span class="secno">5.24</span> <span class="content">CWG2341 Structured bindings with <code class="highlight"><c- k>static</c-></code> storage duration</span></a>
      <li><a href="#CWG2343"><span class="secno">5.25</span> <span class="content">CWG2343 <code class="highlight"><c- b>void</c-><c- o>*</c-></code> non-type template parameters</span></a>
      <li><a href="#CWGZygoloid"><span class="secno">5.26</span> <span class="content">CWG??? unqualified lookup in <i>conversion-type-id</i>s (<span>Sent by Richard Smith to EWG, from CWG</span>)</span></a>
     </ol>
    <li><a href="#telecons"><span class="secno">6</span> <span class="content">Teleconferences</span></a>
    <li><a href="#issues"><span class="secno">7</span> <span class="content">Remaining Open Issues</span></a>
    <li><a href="#future"><span class="secno">8</span> <span class="content">Near-future EWG plans</span></a>
    <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="summary"><span class="secno">1. </span><span class="content">Executive summary</span><a class="self-link" href="#summary"></a></h2>
   <p>We have not met in-person since the February 2020 meeting in Prague because of the global pandemic. We’re instead holding weekly teleconferences, as detailed in <a data-link-type="biblio" href="#biblio-p2145r1">[P2145R1]</a>. We focus on providing non-final guidance, and will use electronic straw polls as detailed in <a data-link-type="biblio" href="#biblio-p2195r0">[P2195R0]</a> to move papers and issues forward in a asynchronous manner.</p>
   <p>Our main achievements have been:</p>
   <ul>
    <li data-md>
     <p><strong>Issue processing</strong>: most of the 50 language evolution issues have proposed resolutions.</p>
    <li data-md>
     <p><strong>C++23</strong>: we’ve started work on papers for C++23 and later.</p>
    <li data-md>
     <p><strong>Incubation</strong>: we’ve acted as EWG-I and "incubated" some early papers by providing early feedback to authors.</p>
   </ul>
   <p>This paper outlines the work achieved, other ongoing work, and lists the straw polls that will be submitted for the February 2021 polling period.</p>
   <h2 class="heading settled" data-level="2" id="note"><span class="secno">2. </span><span class="content">Paper of note</span><a class="self-link" href="#note"></a></h2>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p1000r4">[P1000R4]</a> C++ IS schedule</p>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p0592r4">[P0592R4]</a> To boldly suggest an overall plan for C++23</p>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p1999r0">[P1999R0]</a> Process: double-check evolutionary material via a Tentatively Ready status</p>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p2195r0">[P2195R0]</a> Electronic Straw Polls</p>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p2145r1">[P2145R1]</a> Evolving C++ Remotely</p>
   </ul>
   <h2 class="heading settled" data-level="3" id="tentative"><span class="secno">3. </span><span class="content">Tentatively ready papers</span><a class="self-link" href="#tentative"></a></h2>
   <p>Following our process in <a data-link-type="biblio" href="#biblio-p1999r0">[P1999R0]</a>, we usually mark papers as tentatively ready for CWG. We would usually take a brief look at the next meeting, and if nothing particular concerns anyone, send them to CWG. However, given the pandemic, we’ve decided to provide guidance only in virtual teleconferences, and have an asynchronous polling mechanism to officially send papers to CWG or other groups as detailed in <a data-link-type="biblio" href="#biblio-p2195r0">[P2195R0]</a>. We will be polling to advance all of these papers in the February 2021 polling period, and therefore avoid listing them twice in this paper.</p>
   <p>You can follow the lists of papers on GitHub:</p>
   <ul>
    <li data-md>
     <p><a href="https://github.com/cplusplus/papers/labels/TentativelyReady">tentatively ready papers</a>,</p>
    <li data-md>
     <p><a href="https://github.com/cplusplus/papers/labels/EWG-vote-on-me">EWG vote on me papers</a>.</p>
   </ul>
   <h2 class="heading settled" data-level="4" id="issue-pro"><span class="secno">4. </span><span class="content">Issue Processing</span><a class="self-link" href="#issue-pro"></a></h2>
   <p>We’ve reviewed 50 Language Evolution issues at the Core groups' request, and have tentative resolutions for most. We don’t want to poll all of these at the same time, and will therefore only poll a subset in the February 2021 polling period, reserving other issues for later polling periods. We will therefore only poll the "tentatively ready" issues (since they’re tied to papers, and polled with said papers, as outlined below), as well as the "resolved" issues since telecon attendees believe that prior work has already addressed the issues.</p>
   <p><a href="#issues">§ 7 Remaining Open Issues</a> contains a list of issues which aren’t being voted on in this polling period.</p>
   <h2 class="heading settled" data-level="5" id="polls"><span class="secno">5. </span><span class="content">Polls</span><a class="self-link" href="#polls"></a></h2>
   <p>The current list of polls which EWG will take in the February 2021 polling period are:</p>
   <h3 class="heading settled" data-level="5.1" id="P2223R1"><span class="secno">5.1. </span><span class="content">P2223R1 Trimming whitespaces before line splicing</span><a class="self-link" href="#P2223R1"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p2223r1">[P2223R1]</a></p>
    <li data-md>
     <p><a href="https://github.com/cplusplus/papers/issues/925">GitHub issue</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG14-Oct-2020">Notes 2020-10-14</a></p>
    <li data-md>
     <p>Not yet seen by WG14, nor the SG22 C / C++ liaison group.</p>
    <li data-md>
     <p><strong>Highlight:</strong> make trailing whitespaces after <code class="highlight">\</code> non-significant.</p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Forward P2223R1 "Trimming whitespaces before line splicing" to Core, thereby also fixing <a data-link-type="biblio" href="#biblio-cwg1698">[CWG1698]</a>.</p>
   </ul>
   <h3 class="heading settled" data-level="5.2" id="P2201R0"><span class="secno">5.2. </span><span class="content">P2201R0 Mixed string literal concatenation</span><a class="self-link" href="#P2201R0"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p2201r0">[P2201R0]</a></p>
    <li data-md>
     <p><a href="https://github.com/cplusplus/papers/issues/905">GitHub issue</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2013R2FreestandingLanguage:Optional::operatorNewP2201R0MixedStringLiteralConcatenation-19-Aug-2020">Notes 2020-08-19</a></p>
    <li data-md>
     <p>Seen by WG14 as <a data-link-type="biblio" href="#biblio-n2594">[N2594]</a>, straw Poll: Does the committee wish to adopt N2594 into C23 as is? 18-0-2 passes.</p>
    <li data-md>
     <p><strong>Highlight:</strong> string concatenation involving string-literals with <em>encoding-prefixes</em> mixing <code class="highlight">L<c- s>""</c-></code>, <code class="highlight">u8<c- s>""</c-></code>, <code class="highlight">u<c- s>""</c-></code>, and <code class="highlight">U<c- s>""</c-></code> is currently conditionally-supported with implementation-defined behavior, this paper makes it ill-formed.</p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Forward P2201R0 "Mixed string literal concatenation" to Core, after adding an Annex C entry.</p>
   </ul>
   <h3 class="heading settled" data-level="5.3" id="P2186R1"><span class="secno">5.3. </span><span class="content">P2186R1 Removing Garbage Collection Support</span><a class="self-link" href="#P2186R1"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p2186r1">[P2186R1]</a></p>
    <li data-md>
     <p><a href="https://github.com/cplusplus/papers/issues/898">GitHub issue</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2139R2ReviewingDeprecatedFacilitiesOfC20ForC23P2186R0RemovingGarbageCollectionSupport-30-July-2020">Notes 2020-07-03</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/P2186">Notes 2020-12-14</a></p>
    <li data-md>
     <p><strong>Highlight:</strong> remove (not deprecate) garbage collection support in C++23.</p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Forward P2186R1 "Removing Garbage Collection Support" to Core.</p>
   </ul>
   <h3 class="heading settled" data-level="5.4" id="P2173R0"><span class="secno">5.4. </span><span class="content">P2173R0 Attributes on Lambda-Expressions</span><a class="self-link" href="#P2173R0"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p2173r0">[P2173R0]</a></p>
    <li data-md>
     <p><a href="https://github.com/cplusplus/papers/issues/882">GitHub issue</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020">Notes 2020-04-23</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2156-P2173-2-July-2020">Notes 2020-07-02</a></p>
    <li data-md>
     <p><strong>Highlight:</strong> allow attributes for lambdas, those attributes appertaining to the function call operator of the lambda.</p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Forward P2173R0 "Attributes on Lambda-Expressions" to Core, thereby also fixing <a data-link-type="biblio" href="#biblio-cwg2097">[CWG2097]</a>.</p>
   </ul>
   <h3 class="heading settled" data-level="5.5" id="P2156R1"><span class="secno">5.5. </span><span class="content">P2156R1 Allow Duplicate Attributes</span><a class="self-link" href="#P2156R1"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p2156r1">[P2156R1]</a></p>
    <li data-md>
     <p><a href="https://github.com/cplusplus/papers/issues/864">GitHub issue</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020">Notes 2020-04-15</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020">Notes 2020-04-23</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2156-P2173-2-July-2020">Notes 2020-07-02</a></p>
    <li data-md>
     <p>Seen by WG14 as <a data-link-type="biblio" href="#biblio-n2557">[N2557]</a>, straw Poll: Is the committee in favor of adopting N2557 into C23? 19-0-0 passes.</p>
    <li data-md>
     <p><strong>Highlight:</strong> current limitations on duplicate attributes are inconsistent, this change removes all limitations on duplicate attributes in an attribute-list for all attributes that specify a limitation. This affects <code class="highlight"><c- n>carries_dependency</c-></code>, <code class="highlight"><c- n>deprecated</c-></code>, <code class="highlight"><c- n>fallthrough</c-></code>, <code class="highlight"><c- n>likely</c-></code>, <code class="highlight"><c- n>unlikely</c-></code>, <code class="highlight"><c- n>unused</c-></code>, <code class="highlight"><c- n>noreturn</c-></code>, and <code class="highlight"><c- n>no_unique_address</c-></code>.</p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Forward P2156R1 "Allow Duplicate Attributes" to Core, thereby also fixing <a data-link-type="biblio" href="#biblio-cwg1914">[CWG1914]</a>.</p>
   </ul>
   <h3 class="heading settled" data-level="5.6" id="P2013R3"><span class="secno">5.6. </span><span class="content">P2013R3 Freestanding Language: Optional <code class="highlight"><c- o>::</c-><c- k>operator</c-> <c- k>new</c-></code></span><a class="self-link" href="#P2013R3"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p2013r3">[P2013R3]</a></p>
    <li data-md>
     <p><a href="https://github.com/cplusplus/papers/issues/749">GitHub issue</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21prague/P2013R0-EWG">Notes 2020-02-14</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2013R2FreestandingLanguage:Optional::operatorNewP2201R0MixedStringLiteralConcatenation-19-Aug-2020">Notes 2020-08-19</a></p>
    <li data-md>
     <p>Not yet seen by WG14, nor the SG22 C / C++ liaison group.</p>
    <li data-md>
     <p><strong>Highlight:</strong> on freestanding C++ implementations, make the various default allocating <code class="highlight"><c- o>::</c-><c- k>operator</c-> <c- k>new</c-></code> optional. Placement <code class="highlight"><c- k>new</c-></code> is still required. All <code class="highlight"><c- o>::</c-><c- k>operator</c-> <c- k>delete</c-></code> are still required. Hosted implementations are unchanged.</p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Forward P2013R3 "Freestanding Language: Optional <code class="highlight"><c- o>::</c-><c- k>operator</c-> <c- k>new</c-></code>" to Core.</p>
   </ul>
   <h3 class="heading settled" data-level="5.7" id="P1949R6"><span class="secno">5.7. </span><span class="content">P1949R6 C++ Identifier Syntax using Unicode Standard Annex 31</span><a class="self-link" href="#P1949R6"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p1949r6">[P1949R6]</a></p>
    <li data-md>
     <p><a href="https://github.com/cplusplus/papers/issues/688">GitHub issue</a></p>
    <li data-md>
     <p><a href="https://github.com/sg16-unicode/sg16/issues/48">SG16 Unicode group tracking GitHub issue</a></p>
    <li data-md>
     <p>C++20 NB comment <a href="https://github.com/cplusplus/nbballot/issues/28">NL029 05.10</a></p>
    <li data-md>
     <p><a href="http://wiki.edg.com/bin/view/Wg21belfast/SG16NBNL029">Notes 2019-12-19</a></p>
    <li data-md>
     <p><a href="http://wiki.edg.com/bin/view/Wg21prague/SG16P1949R1">Notes 2020-02-12</a></p>
    <li data-md>
     <p><a href="http://wiki.edg.com/bin/view/Wg21prague/SG17P1949R1">Notes 2020-02-13</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21prague/D1949R2-EWG">Notes 2020-02-14</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1949-18-June-2020">Notes 2020-06-18</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1949-24-Sep-2020">Notes 2020-09-24</a></p>
    <li data-md>
     <p>Not yet seen by WG14, nor the SG22 C / C++ liaison group.</p>
    <li data-md>
     <p><strong>Highlight:</strong> C++11 uses a hand-curated list of Unicode codepoints to determine which characters are allowed in identifiers. This is flawed in many ways outlined in the paper. Replace this hand-curated list with the Unicode consortium’s recommendations for identifiers <a data-link-type="biblio" href="#biblio-uax31">[UAX31]</a>.</p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Forward P1949R6 "C++ Identifier Syntax using Unicode Standard Annex 31" to Core.</p>
   </ul>
   <h3 class="heading settled" data-level="5.8" id="P1938R2"><span class="secno">5.8. </span><span class="content">P1938R2 <code class="highlight"><c- k>if</c-> <c- k>consteval</c-></code></span><a class="self-link" href="#P1938R2"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p1938r2">[P1938R2]</a></p>
    <li data-md>
     <p><a href="https://github.com/cplusplus/papers/issues/677">GitHub issue</a></p>
    <li data-md>
     <p>C++20 NB comment <a href="https://github.com/cplusplus/nbballot/issues/219">FR22 20.15.10</a>, discussed in <a href="http://wiki.edg.com/bin/view/Wg21belfast/FR222">Belfast</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21prague/P1938R0-EWG">Notes 2020-02-14</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-8-Oct-2020">Notes 2020-10-08</a></p>
    <li data-md>
     <p><strong>Highlight:</strong> C++20 added <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>is_constant_evaluated</c-><c- p>()</c-></code> and <code class="highlight"><c- k>consteval</c-></code>, which interact poorly with each other. This paper adds a new form of <code class="highlight"><c- k>if</c-></code> statement to address the poor interaction.</p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Forward P1938R2 "<code class="highlight"><c- k>if</c-> <c- k>consteval</c-></code>" to Core.</p>
   </ul>
   <h3 class="heading settled" data-level="5.9" id="P1847R3"><span class="secno">5.9. </span><span class="content">P1847R3 Make declaration order layout mandated</span><a class="self-link" href="#P1847R3"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p1847r3">[P1847R3]</a></p>
    <li data-md>
     <p><a href="https://github.com/cplusplus/papers/issues/600">GitHub issue</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21belfast/P1847">Notes 2019-11-05</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21prague/P1847R2-EWG">Notes 2020-02-13</a></p>
    <li data-md>
     <p><strong>Highlight:</strong> C++ currently lets compilers reorder data member layout if they have different access controls. Compilers don’t take advantage of this permission. This paper removes the unused flexibility.</p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Forward P1847R3 "Make declaration order layout mandated" to Core.</p>
   </ul>
   <h3 class="heading settled" data-level="5.10" id="P1401R4"><span class="secno">5.10. </span><span class="content">P1401R4 Narrowing contextual conversions to <code class="highlight"><c- b>bool</c-></code></span><a class="self-link" href="#P1401R4"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p1401r4">[P1401R4]</a></p>
    <li data-md>
     <p><a href="https://github.com/cplusplus/papers/issues/188">GitHub issue</a></p>
    <li data-md>
     <p>Addresses <a data-link-type="biblio" href="#biblio-cwg2320">[CWG2320]</a>, which was caused by resolving <a data-link-type="biblio" href="#biblio-cwg2039">[CWG2039]</a>, see <a href="https://lists.isocpp.org/core/2016/09/0899.php">Richard Smith’s email regarding this approach</a>.</p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21prague/P1401R2-EWG">Notes 2020-02-12</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-30-Sep-2020">Notes 2020-09-30</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG28-Oct-2020">Notes 2020-10-28</a></p>
    <li data-md>
     <p><strong>Highlight:</strong> allow conversions from integral types to type <code class="highlight"><c- b>bool</c-></code> in <code class="highlight"><c- k>static_assert</c-></code> and <code class="highlight"><c- k>if</c-> <c- k>constexpr</c-></code>-statements.</p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Forward P1401R4 "Narrowing contextual conversions to <code class="highlight"><c- b>bool</c-></code>" to Core.</p>
   </ul>
   <h3 class="heading settled" data-level="5.11" id="P1393R0"><span class="secno">5.11. </span><span class="content">P1393R0 A General Property Customization Mechanism</span><a class="self-link" href="#P1393R0"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-p1393r0">[P1393R0]</a></p>
    <li data-md>
     <p><a href="https://github.com/cplusplus/papers/issues/185">GitHub issue</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1393-21-May-2020">Notes 2020-05-21</a></p>
    <li data-md>
     <p><strong>Highlight:</strong> "properties" are a customization mechanism at the center of <a data-link-type="biblio" href="#biblio-p0443r14">[P0443R14]</a> executors. The proposed approach is library-only, but it could be possible to develop a language-based approach instead. The discussion and poll’s goal are to avoid a late-changing redesign of executors based on wanting a language-based approach for customization.</p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> We understand properties and think that specifying them purely in library is the right approach.</p>
   </ul>
   <h3 class="heading settled" data-level="5.12" id="CWG2169"><span class="secno">5.12. </span><span class="content">CWG2169 Narrowing conversions and overload resolution</span><a class="self-link" href="#CWG2169"></a></h3>
   <ul>
    <li><a data-link-type="biblio" href="#biblio-cwg2169">[CWG2169]</a> 
    <li>
     <blockquote>
      <p>Current implementations ignore narrowing conversions during overload resolution, emitting a diagnostic if calling the selected function would involve narrowing. For example: </p>
<pre class="highlight"><c- k>struct</c-> <c- n>s</c-> <c- p>{</c-> <c- b>long</c-> <c- n>m</c-> <c- p>};</c->
<c- k>struct</c-> <c- n>ss</c-> <c- p>{</c-> <c- b>short</c-> <c- n>m</c-><c- p>;</c-> <c- p>};</c->
<c- b>void</c-> <c- nf>f</c-><c- p>(</c-> <c- n>ss</c-> <c- p>);</c->
<c- b>void</c-> <c- nf>f</c-><c- p>(</c-> <c- n>s</c-> <c- p>);</c->
<c- b>void</c-> <c- nf>g</c-><c- p>()</c-> <c- p>{</c->
  <c- n>f</c-><c- p>({</c-> <c- mi>1000000</c-> <c- p>});</c-> <c- c1>// Ambiguous in spite of narrowing for f(ss)</c->
<c- p>}</c->
</pre>
      <p>However, the current wording of 12.4.3.1.5 [over.ics.list] paragraph 7 says, </p>
      <blockquote>Otherwise, if the parameter has an aggregate type which can be initialized from the initializer list according to the rules for aggregate initialization (9.4.1 [dcl.init.aggr]), the implicit conversion sequence is a user-defined conversion sequence with the second standard conversion sequence an identity conversion.</blockquote>
      <p>In the example above, <code class="highlight"><c- n>ss</c-></code> cannot be initialized from <code class="highlight"><c- p>{</c-> <c- mi>1000000</c-> <c- p>}</c-></code> because of the narrowing conversion, so presumably <code class="highlight"><c- n>f</c-><c- p>(</c-><c- n>ss</c-><c- p>)</c-></code> should not be considered. If this is not the intended outcome, paragraph 7 should be restated in terms of having an implicit conversion sequence, as in, e.g., bullet 9.1, instead of a valid initialization. </p>
     </blockquote>
    <li><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-29-Apr-2020">Notes 2020-04-29</a> 
    <li><a href="https://lists.isocpp.org/ext/2020/10/15157.php">JF’s email to EWG 2020-10-19</a>, with the follow-up suggestion that no paper was needed and CWG could resolve the issue if given guidance from EWG. 
    <li>🗳 <strong>Poll:</strong> Guidance to Core: implementations are right, the Standard needs to be fixed to address this issue by following existing implementations. 
   </ul>
   <h3 class="heading settled" data-level="5.13" id="CWG2355"><span class="secno">5.13. </span><span class="content">CWG2355 Deducing <i>noexcept-specifiers</i></span><a class="self-link" href="#CWG2355"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-cwg2355">[CWG2355]</a></p>
    <li data-md>
     <p>The list of deducible forms in 13.10.2.5 [temp.deduct.type] paragraph 8 does not include the ability to deduce the value of the constant in a noexcept-specifier, although implementations appear to allow it. Note: multiple standard library implementations rely on it.</p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-07-May-2020">Notes 2020-05-07</a></p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Guidance to Core: modify the Standard such that the value of a constant in a <i>noexcept-specifier</i> can be deduced.</p>
   </ul>
   <h3 class="heading settled" data-level="5.14" id="CWG476"><span class="secno">5.14. </span><span class="content">CWG476 Determining the buffer size for placement <code class="highlight"><c- k>new</c-></code></span><a class="self-link" href="#CWG476"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-cwg476">[CWG476]</a></p>
    <li data-md>
     <p>Resolved by <a data-link-type="biblio" href="#biblio-cwg2382">[CWG2382]</a> (no overhead for placement <code class="highlight"><c- k>new</c-></code> for arrays). CWG2382 was moved in Belfast as part of <a data-link-type="biblio" href="#biblio-p1969r0">[P1969r0]</a>.</p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020">Notes 2020-04-09</a></p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Mark CWG476 "Determining the buffer size for placement <code class="highlight"><c- k>new</c-></code>" as resolved by P1969r0, and a duplicate of CWG2382.</p>
   </ul>
   <h3 class="heading settled" data-level="5.15" id="CWG687"><span class="secno">5.15. </span><span class="content">CWG687 <code class="highlight"><c- k>template</c-></code> keyword with <i>unqualified-id</i>s</span><a class="self-link" href="#CWG687"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-cwg687">[CWG687]</a></p>
    <li data-md>
     <p>Resolved by <a data-link-type="biblio" href="#biblio-p0846r0">[P0846r0]</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020">Notes 2020-04-09</a></p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Mark CWG687 "<code class="highlight"><c- k>template</c-></code> keyword with <i>unqualified-id</i>s" as resolved by P0846r0.</p>
   </ul>
   <h3 class="heading settled" data-level="5.16" id="CWG1326"><span class="secno">5.16. </span><span class="content">CWG1326 Deducing an array bound from an <i>initializer-list</i></span><a class="self-link" href="#CWG1326"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-cwg1326">[CWG1326]</a></p>
    <li data-md>
     <p>Resolved by <a data-link-type="biblio" href="#biblio-p0127r2">[P0127R2]</a> Declaring non-type <code class="highlight"><c- k>template</c-></code> parameters with <code class="highlight"><c- k>auto</c-></code>, and <a data-link-type="biblio" href="#biblio-cwg1591">[CWG1591]</a>.</p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020">Notes 2020-04-09</a></p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Mark CWG1326 "Deducing an array bound from an <i>initializer-list</i>" as resolved by P0127R2, and a duplicate of CWG1591.</p>
   </ul>
   <h3 class="heading settled" data-level="5.17" id="CWG1331"><span class="secno">5.17. </span><span class="content">CWG1331 <code class="highlight"><c- k>const</c-></code> mismatch with defaulted copy constructor</span><a class="self-link" href="#CWG1331"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-cwg1331">[CWG1331]</a></p>
    <li data-md>
     <p>Resolved by <a data-link-type="biblio" href="#biblio-p0641r2">[P0641r2]</a> (whose title is Resolving Core Issue #1331, also resolves <a data-link-type="biblio" href="#biblio-cwg1426">[CWG1426]</a>).</p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21rapperswil2014/EvolutionWorkingGroup">Notes 2014-06-21</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020">Notes 2020-04-09</a></p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Mark CWG1331 "<code class="highlight"><c- k>const</c-></code> mismatch with defaulted copy constructor" as resolved by P0641r2.</p>
   </ul>
   <h3 class="heading settled" data-level="5.18" id="CWG1393"><span class="secno">5.18. </span><span class="content">CWG1393 Pack expansions in <i>using-declaration</i>s</span><a class="self-link" href="#CWG1393"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-cwg1393">[CWG1393]</a></p>
    <li data-md>
     <p>Resolved by <a data-link-type="biblio" href="#biblio-p0195r2">[P0195r2]</a> (same title as issue)</p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21rapperswil2014/EvolutionWorkingGroup">Notes 2014-06-21</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020">Notes 2020-04-09</a></p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Mark CWG1393 "Pack expansions in <i>using-declaration</i>s" as resolved by P0195r2.</p>
   </ul>
   <h3 class="heading settled" data-level="5.19" id="CWG1426"><span class="secno">5.19. </span><span class="content">CWG1426 Allowing additional parameter types in defaulted functions</span><a class="self-link" href="#CWG1426"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-cwg1426">[CWG1426]</a></p>
    <li data-md>
     <p>Resolved by <a data-link-type="biblio" href="#biblio-p0641r2">[P0641r2]</a> (also resolves <a data-link-type="biblio" href="#biblio-cwg1331">[CWG1331]</a>)</p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020">Notes 2020-04-09</a></p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Mark CWG1426 "Allowing additional parameter types in defaulted functions" as resolved by P0641r2.</p>
   </ul>
   <h3 class="heading settled" data-level="5.20" id="CWG1561"><span class="secno">5.20. </span><span class="content">CWG1561 Aggregates with empty base classes</span><a class="self-link" href="#CWG1561"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-cwg1561">[CWG1561]</a></p>
    <li data-md>
     <p>Resolved by <a data-link-type="biblio" href="#biblio-p0017r1">[P0017r1]</a> (which allowed aggregates to have base classes)</p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21rapperswil2014/EvolutionWorkingGroup">Notes 2014-06-21</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020">Notes 2020-04-15</a></p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Mark CWG1561 "Aggregates with empty base classes" as resolved by P0017r1.</p>
   </ul>
   <h3 class="heading settled" data-level="5.21" id="CWG1912"><span class="secno">5.21. </span><span class="content">CWG1912 <i>exception-specification</i> of defaulted function</span><a class="self-link" href="#CWG1912"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-cwg1912">[CWG1912]</a></p>
    <li data-md>
     <p>The current rules requiring a defaulted member function to have an exception-specification compatible with that of the implicitly-declared function are overly constraining. It should be possible, for example, to specify that a defaulted move constructor will be non-throwing, based on knowledge available to the programmer, even if the implicitly-declared constructor would be throwing.</p>
    <li data-md>
     <p>Resolved by <a data-link-type="biblio" href="#biblio-p1286r2">[p1286r2]</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020">Notes 2020-04-23</a></p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Mark CWG1912 "<i>exception-specification</i> of defaulted function" as resolved by p1286r2.</p>
   </ul>
   <h3 class="heading settled" data-level="5.22" id="CWG1931"><span class="secno">5.22. </span><span class="content">CWG1931 Default-constructible and copy-assignable closure types</span><a class="self-link" href="#CWG1931"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-cwg1931">[CWG1931]</a></p>
    <li data-md>
     <p>Resolved by <a data-link-type="biblio" href="#biblio-p0624r2">[P0624r2]</a> Default constructible and assignable stateless lambdas</p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020">Notes 2020-04-23</a></p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Mark CWG1931 "Default-constructible and copy-assignable closure types" as resolved by P0624r2.</p>
   </ul>
   <h3 class="heading settled" data-level="5.23" id="CWG2295"><span class="secno">5.23. </span><span class="content">CWG2295 Aggregates with deleted defaulted constructors</span><a class="self-link" href="#CWG2295"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-cwg2295">[CWG2295]</a></p>
    <li data-md>
     <p>Should a class with a deleted non-user-provided default constructor be considered an aggregate?</p>
    <li data-md>
     <p>Resolved by <a data-link-type="biblio" href="#biblio-p1008r1">[P1008r1]</a> Prohibit aggregates with user-declared constructors</p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-07-May-2020">Notes 2020-05-07</a></p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Mark CWG2295 "Aggregates with deleted defaulted constructors" as resolved by P1008r1.</p>
   </ul>
   <h3 class="heading settled" data-level="5.24" id="CWG2341"><span class="secno">5.24. </span><span class="content">CWG2341 Structured bindings with <code class="highlight"><c- k>static</c-></code> storage duration</span><a class="self-link" href="#CWG2341"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-cwg2341">[CWG2341]</a></p>
    <li data-md>
     <p>Resolved by <a data-link-type="biblio" href="#biblio-p1091r3">[P1091r3]</a> Extending structured bindings to be more like variable declarations</p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-07-May-2020">Notes 2020-05-07</a></p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Mark CWG2341 "Structured bindings with <code class="highlight"><c- k>static</c-></code> storage duration" as resolved by P1091r3.</p>
   </ul>
   <h3 class="heading settled" data-level="5.25" id="CWG2343"><span class="secno">5.25. </span><span class="content">CWG2343 <code class="highlight"><c- b>void</c-><c- o>*</c-></code> non-type template parameters</span><a class="self-link" href="#CWG2343"></a></h3>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-cwg2343">[CWG2343]</a></p>
    <li data-md>
     <p>According to 13.2 [temp.param] bullet 4.2, non-type template parameters of pointer type must be either pointer to object or pointer to function. This excludes <code class="highlight"><c- b>void</c-><c- o>*</c-></code>, which is an object pointer but not a pointer to object. However, most or all current implementations accept <code class="highlight"><c- b>void</c-><c- o>*</c-></code> as a non-type template parameter. Notes from the April, 2018 Core teleconference: Not all implementations accept a <code class="highlight"><c- b>void</c-><c- o>*</c-></code> template parameter, so this should not be a DR if it is eventually adopted. Furthermore, there is some implementation divergence over the kinds of template arguments that can be passed to a <code class="highlight"><c- b>void</c-><c- o>*</c-></code> template parameter.</p>
    <li data-md>
     <p>Resolved by <a data-link-type="biblio" href="#biblio-p0732r2">[P0732R2]</a> (which used <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>strong_ordering</c-></code> in defining strong structural equality and used that for NTTPs) because <a data-link-type="biblio" href="#biblio-p0515r3">[P0515R3]</a> had given <code class="highlight"><c- o>&lt;=></c-></code> the type <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>strong_ordering</c-></code> for "object pointers" (which includes <code class="highlight"><c- b>void</c-><c- o>*</c-></code>, even though void is not an object type). Later <a data-link-type="biblio" href="#biblio-p1907r1">[P1907R1]</a> replaced all that, saying simply that structural types (which include all scalar types) were acceptable, but that didn’t change <code class="highlight"><c- b>void</c-><c- o>*</c-></code>'s status. Davis <a href="http://lists.isocpp.org/ext/2020/05/13730.php">emailed EWG the above text</a>.</p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-07-May-2020">Notes 2020-05-07</a></p>
    <li data-md>
     <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG28-Oct-2020">Notes 2020-10-28</a></p>
    <li data-md>
     <p>🗳 <strong>Poll:</strong> Mark CWG2343 "<code class="highlight"><c- b>void</c-><c- o>*</c-></code> non-type template parameters" as resolved by P0732R2.</p>
   </ul>
   <h3 class="heading settled" data-level="5.26" id="CWGZygoloid"><span class="secno">5.26. </span><span class="content">CWG??? unqualified lookup in <i>conversion-type-id</i>s (<a href="https://lists.isocpp.org/ext/2020/06/14037.php">Sent by Richard Smith to EWG, from CWG</a>)</span><a class="self-link" href="#CWGZygoloid"></a></h3>
   <ul>
    <li>
     <blockquote>
      The basic situation looks like this: 
<pre class="highlight"><c- k>struct</c-> <c- n>A</c-> <c- p>{</c->
  <c- k>struct</c-> <c- n>B</c-> <c- p>{};</c->
  <c- k>operator</c-> <c- nf>B</c-><c- p>();</c->
<c- p>};</c->
<c- b>void</c-> <c- nf>f</c-><c- p>(</c-><c- n>A</c-> <c- n>a</c-><c- p>)</c-> <c- p>{</c-> <c- n>a</c-><c- p>.</c-><c- k>operator</c-> <c- n>B</c-><c- p>();</c-> <c- p>}</c->
</pre>
      <p>There is a special-case lookup rule that allows this code to work: when looking up the <code class="highlight"><c- n>B</c-></code> in <code class="highlight"><c- n>a</c-><c- p>.</c-><c- k>operator</c-> <c- n>B</c-><c- p>()</c-></code>, we look inside <code class="highlight"><c- n>a</c-></code>. Presumably the intent is to allow <code class="highlight"><c- k>operator</c-> <c- n>B</c-></code> to be named in the same way when it’s referenced as it was named when it was declared. This is a fairly general rule: in <code class="highlight"><c- o>&lt;</c-><c- n>some</c-> <c- n>context</c-><c- o>></c-><c- k>operator</c-> <c- n>B</c-></code>, we look up the <code class="highlight"><c- n>B</c-></code> in the same place in which we later look up the name <code class="highlight"><c- k>operator</c-> <c- n>B</c-></code>.</p>
      <p><em>Question</em> The issue we are facing is: exactly what lookups does the special-case rule apply to? Consider a few examples: </p>
<pre class="highlight"><c- n>a</c-><c- p>.</c-><c- k>operator</c-> <c- n>B</c-><c- o>&lt;</c-><c- n>C</c-><c- o>></c-><c- p>();</c->
<c- n>a</c-><c- p>.</c-><c- k>operator</c-> <c- n>B</c-> <c- n>D</c-><c- o>::*</c-><c- p>();</c->
<c- n>a</c-><c- p>.</c-><c- k>operator</c-> <c- k>decltype</c-><c- p>(</c-><c- n>E</c-><c- p>)();</c->
</pre>
      <p>Which of <code class="highlight"><c- n>B</c-></code>, <code class="highlight"><c- n>C</c-></code>, <code class="highlight"><c- n>D</c-></code>, and <code class="highlight"><c- n>E</c-></code> get the special "look this name up in <code class="highlight"><c- n>a</c-></code>" rule?</p>
      <p>There is implementation divergence: </p>
      <ul>
       <li>Clang says none. 
       <li>EDG and MSVC say <code class="highlight"><c- n>B</c-></code> only. 
       <li>GCC says <code class="highlight"><c- n>B</c-></code> and <code class="highlight"><c- n>D</c-></code>. 
       <li>And the consistent rules we’re looking at now would say all of <code class="highlight"><c- n>B</c-></code>, <code class="highlight"><c- n>C</c-></code>, <code class="highlight"><c- n>D</c-></code>, and <code class="highlight"><c- n>E</c-></code> are looked up in <code class="highlight"><c- n>A</c-></code>. 
      </ul>
     </blockquote>
    <li>Resolved by <a data-link-type="biblio" href="#biblio-p1787r6">[P1787R6]</a>. 
    <li><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG28-Oct-2020">Notes 2020-10-28</a> 
    <li>🗳 <strong>Poll:</strong> Mark the CWG issue sent by Richard Smith to EWG on 2020-06 "unqualified lookup in <i>conversion-type-id</i>s" as resolved by P1787R6. 
   </ul>
   <p>For each poll, you will be asked to vote one of:</p>
   <ul>
    <li data-md>
     <p>Strongly in favor</p>
    <li data-md>
     <p>In favor</p>
    <li data-md>
     <p>Neutral</p>
    <li data-md>
     <p>Against</p>
    <li data-md>
     <p>Strongly against</p>
   </ul>
   <p>You will also have the option to abstain from voting on a particular poll. You will be asked to comment on each poll. This comment is mandatory, as it helps the chair determine consensus.</p>
   <h2 class="heading settled" data-level="6" id="telecons"><span class="secno">6. </span><span class="content">Teleconferences</span><a class="self-link" href="#telecons"></a></h2>
   <p>Here are the minutes for the virtual discussions that were held since the Prague meeting in February 2020:</p>
   <ol>
    <li>2020-04-09 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020">Issue Processing</a> 
    <li>2020-04-15 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020">Issue Processing</a> 
    <li>2020-04-23 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020">Issue Processing</a> 
    <li>2020-04-29 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-29-Apr-2020">Issue Processing</a> 
    <li>2020-05-07 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-07-May-2020">Issue Processing</a> 
    <li>2020-05-13 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-13-May-2020">Issue Processing</a> 
    <li>2020-05-21 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1393-21-May-2020">A General Property Customization Mechanism</a>—<a data-link-type="biblio" href="#biblio-p1393r0">[P1393R0]</a> (<a href="https://wg21.link/P1393/github">P1393 tracking issue</a>) 
    <li>2020-06-10 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-D2139R1-10-June-2020">Reviewing Deprecated Facilities of C++20 for C++23</a>—<a data-link-type="biblio" href="#biblio-p2139r1">[P2139R1]</a> (<a href="https://wg21.link/P2139/github">P2139 tracking issue</a>) 
    <li>2020-06-18 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1949-18-June-2020">C++ Identifier Syntax using Unicode Standard Annex 31</a>—<a data-link-type="biblio" href="#biblio-p1949r4">[P1949R4]</a> (<a href="https://wg21.link/P1949/github">P1949 tracking issue</a>) 
    <li>2020-06-24 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1467-24-June-2020">Extended floating-point types and standard names</a>—<a data-link-type="biblio" href="#biblio-p1467r4">[P1467R4]</a> (<a href="https://wg21.link/P1467/github">P1467 tracking issue</a>) 
    <li>2020-07-02 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2156-P2173-2-July-2020">Allow Duplicate Attributes, Attributes on Lambda-Expressions</a>—<a data-link-type="biblio" href="#biblio-p2156r0">[P2156R0]</a> (<a href="https://wg21.link/P2156/github">P2156 tracking issue</a>) and <a data-link-type="biblio" href="#biblio-p2173r0">[P2173R0]</a> (<a href="https://wg21.link/P2173/github">P2173 tracking issue</a>) 
    <li>2020-07-08 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1726R3-8-July-2020">Pointer lifetime-end zap and provenance, too</a>—<a data-link-type="biblio" href="#biblio-p1726r3">[P1726R3]</a> (<a href="https://wg21.link/P1726/github">P1726 tracking issue</a>) 
    <li>2020-07-16 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1726R3-16-July-2020">Guaranteed copy elision for return variables</a>—<a data-link-type="biblio" href="#biblio-p2025r1">[P2025R1]</a> (<a href="https://wg21.link/P2025/github">P2025 tracking issue</a>) 
    <li>2020-07-30 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2139R2ReviewingDeprecatedFacilitiesOfC20ForC23P2186R0RemovingGarbageCollectionSupport-30-July-2020">Reviewing Deprecated Facilities of C++20 for C++23, Removing Garbage Collection Support</a>—<a data-link-type="biblio" href="#biblio-p2139r2">[P2139R2]</a> (<a href="https://wg21.link/P2139/github">P2139 tracking issue</a>) and <a data-link-type="biblio" href="#biblio-p2186r0">[P2186R0]</a> (<a href="https://wg21.link/P2186/github">P2186 tracking issue</a>) 
    <li>2020-08-05 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1875R0-5-Aug-2020">Transactional Memory Lite Support in C++</a>—<a data-link-type="biblio" href="#biblio-p1875r0">[P1875R0]</a> (<a href="https://wg21.link/P1875/github">P1875 tracking issue</a>) 
    <li>2020-08-19 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2013R2FreestandingLanguage:Optional::operatorNewP2201R0MixedStringLiteralConcatenation-19-Aug-2020">Freestanding Language: Optional <code class="highlight"><c- o>::</c-><c- k>operator</c-> <c- k>new</c-></code>, Mixed string literal concatenation</a>—<a data-link-type="biblio" href="#biblio-p2013r2">[P2013R2]</a> (<a href="https://wg21.link/P2013/github">P2013 tracking issue</a>) and <a data-link-type="biblio" href="#biblio-p2201r0">[P2201R0]</a> (<a href="https://wg21.link/P2201/github">P2201 tracking issue</a>) 
    <li>2020-08-27 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-D2211R0-27-Aug-2020">Exhaustiveness Checking for Pattern Matching</a>—<a data-link-type="biblio" href="#biblio-p1371r3">[P1371R3]</a> (<a href="https://wg21.link/P1371/github">P1371 tracking issue</a>) 
    <li>2020-09-02 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1967-02-Sep-2020"><code class="highlight"><c- cp>#embed</c-></code> - a simple, scannable preprocessor-based resource acquisition method</a>—<a data-link-type="biblio" href="#biblio-p1967r2">[P1967R2]</a> (<a href="https://wg21.link/P1967/github">P1967 tracking issue</a>) 
    <li>2020-09-10 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2011R1-10-Sep-2020">A pipeline-rewrite operator</a>—<a data-link-type="biblio" href="#biblio-p2011r1">[P2011R1]</a> (<a href="https://wg21.link/P2011/github">P2011 tracking issue</a>) 
    <li>2020-09-16 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1371-16-Sep-2020">Pattern matching: inspect is always an expression</a>—<a data-link-type="biblio" href="#biblio-p1371r3">[P1371R3]</a> (<a href="https://wg21.link/P1371/github">P1371 tracking issue</a>) 
    <li>2020-09-24 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1949-24-Sep-2020">C++ Identifier Syntax using Unicode Standard Annex 31, Member Templates for Local Classes</a>—<a data-link-type="biblio" href="#biblio-p1949r6">[P1949R6]</a> (<a href="https://wg21.link/P1949/github">P1949 tracking issue</a>) and <a data-link-type="biblio" href="#biblio-p2044r0">[P2044R0]</a> (<a href="https://wg21.link/P2044/github">P2044 tracking issue</a>) 
    <li>2020-09-30 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-30-Sep-2020">Narrowing contextual conversions to bool, Generalized pack declaration and usage</a>—<a data-link-type="biblio" href="#biblio-p1401r3">[P1401R3]</a> (<a href="https://wg21.link/P1401/github">P1401 tracking issue</a>) and <a data-link-type="biblio" href="#biblio-p1858r2">[P1858R2]</a> (<a href="https://wg21.link/P1858/github">P1858 tracking issue</a>) 
    <li>2020-10-08 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-8-Oct-2020">Compound Literals, <code class="highlight"><c- k>if</c-> <c- k>consteval</c-></code></a>—<a data-link-type="biblio" href="#biblio-p2174r0">[P2174R0]</a> (<a href="https://wg21.link/P2174/github">P2174 tracking issue</a>) and <a data-link-type="biblio" href="#biblio-p1938r1">[P1938R1]</a> (<a href="https://wg21.link/P1938/github">P1938 tracking issue</a>) 
    <li>2020-10-14 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG14-Oct-2020">Inline Namespaces: Fragility Bites, Trimming whitespaces before line splicing</a>—<a data-link-type="biblio" href="#biblio-p1701r1">[P1701R1]</a> (<a href="https://wg21.link/P1701/github">P1701 tracking issue</a>) and <a data-link-type="biblio" href="#biblio-p2223r0">[P2223R0]</a> (<a href="https://wg21.link/P2223/github">P2223 tracking issue</a>) 
    <li>2020-10-22 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG22-Oct-2020">Issues Processing</a> 
    <li>2020-10-28 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG28-Oct-2020">Issues Processing</a> 
    <li>2020-11-05 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG05-Nov-2020">Deducing <code class="highlight"><c- k>this</c-></code></a>—<a href="https://wg21.link/P0847r5">P0847R5</a> (<a href="https://wg21.link/P0847/github">P0847 tracking issue</a>) 
    <li>2020-11-19 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG19-Nov-2020"><code class="highlight"><c- k>goto</c-></code> in pattern matching</a> 
    <li>2020-12-03 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG03-Dec-2020"><code class="highlight"><c- k>auto</c-><c- p>(</c-><c- n>x</c-><c- p>)</c-></code>: decay-copy in the language</a>—<a href="https://wg21.link/P0849r5">P0849R5</a> (<a href="https://wg21.link/P0849/github">P0849 tracking issue</a>) 
    <li>2021-01-14 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/Polls-2021-01-14">Polls</a> 
   </ol>
   <h2 class="heading settled" data-level="7" id="issues"><span class="secno">7. </span><span class="content">Remaining Open Issues</span><a class="self-link" href="#issues"></a></h2>
   <p>The following table lists all remaining open issues referred to EWG by Core or Library. Some of them are ready to be polled but are held back from the February 2021 polling period to limit the number of polls in this round.</p>
   <table cellpadding="0" cellspacing="0">
    <tbody>
     <tr>
      <td valign="middle">
       <p><b>From</b></p>
      <td valign="top">
       <p><b>#</b></p>
      <td valign="top">
       <p><b>Title</b></p>
      <td valign="top">
       <p><b>Notes</b></p>
      <td valign="top">
       <p><b>Resolution</b></p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg2261">[CWG2261]</a></p>
      <td valign="top">
       <p>Explicit instantiation of in-class <code class="highlight"><c- k>friend</c-></code> definition</p>
      <td valign="top">
<pre class="highlight"><c- k>struct</c-> <c- n>S</c-> <c- p>{</c-> 
   <c- k>template</c-> <c- o>&lt;</c-><c- k>class</c-> <c- nc>T</c-><c- o>></c-> <c- k>friend</c-> <c- b>void</c-> <c- n>f</c-><c- p>(</c-><c- n>T</c-><c- p>)</c-> <c- p>{</c-> <c- p>}</c-> 
  <c- p>};</c-> 
  <c- k>template</c-> <c- b>void</c-> <c- nf>f</c-><c- p>(</c-><c- b>int</c-><c- p>);</c->  <c- c1>// Well-formed?</c->
</pre>
       <p>A <code class="highlight"><c- k>friend</c-></code> is not found by ordinary name lookup until it is explicitly declared in the containing namespace, but declaration matching does not use ordinary name lookup. There is implementation divergence on the handling of this example.</p>
       <p><br></p>
       <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-29-Apr-2020">Note 2020-04-29</a> Tentative agreement: This should be well-formed.</p>
       <p>SF 1 F 10 N 2 A 1 SA 0 </p>
       <p>JF <a href="https://lists.isocpp.org/ext/2020/05/13708.php"><span>emailed EWG / Core about this</span></a>.</p>
       <p>Davis: the current name lookup approach which Core is taking in p1787 would disallow this. Supporting this is possible, it would be inconsistent, but would also be a feature.</p>
       <p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG22-Oct-2020">Notes 2020-10-22</a>: wait until p1787 is voted into the working draft, because it’s making this behavior intentional. At that point, we can vote on marking the issue as Not a Defect. No objection to unanimous consent.</p>
      <td valign="top">
       <p>♻️</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg2270">[CWG2270]</a></p>
      <td valign="top">
       <p>Non-<code class="highlight"><c- kr>inline</c-></code> functions and explicit instantiation declarations</p>
      <td valign="top">
       <p>[Detailed description pending.]</p>
       <p><b>Hubert:</b> question over the role of the <code class="highlight"><c- kr>inline</c-></code> keyword in relation to explicit instantiation declarations.</p>
       <p>For <code class="highlight"><c- kr>inline</c-></code> functions, explicit instantiation declarations do not have the effect of suppressing implicit instantiation.</p>
       <p>A user’s desire for wanting to suppress implicit instantiation can arise for different reasons:</p>
       <p>To reduce space in object files, executables, etc. and similarly to reduce the number of input symbols to the linker</p>
       <p>To reduce compile time in performing semantic analysis for instantiations whose definitions are provided elsewhere</p>
       <p>To control point-of-instantiation, avoiding contexts where the requisite declarations are not declared</p>
       <p>The special rule around inline functions allows <code class="highlight"><c- kr>inline</c-></code>-ness to be used to indicate that the first reason is the intent and that instantiation-for-inlining is okay.</p>
       <p>Consider the following as a translation unit:</p>
<pre class="highlight"><c- k>template</c-> <c- o>&lt;</c-><c- k>typename</c-> <c- n>T</c-><c- o>></c->
<c- c1>//inline</c->
<c- b>void</c-> <c- n>f</c-><c- p>(</c-><c- n>T</c-> <c- n>t</c-><c- p>)</c-> <c- p>{</c-> <c- n>g</c-><c- p>(</c-><c- n>t</c-><c- p>);</c-> <c- p>}</c->
<c- k>enum</c-> <c- nl>E</c-> <c- p>:</c-> <c- b>int</c-><c- p>;</c->
<c- k>extern</c-> <c- k>template</c-> <c- b>void</c-> <c- nf>f</c-><c- p>(</c-><c- n>E</c-><c- p>);</c->
<c- b>void</c-> <c- nf>h</c-><c- p>(</c-><c- n>E</c-> <c- n>e</c-><c- p>)</c-> <c- p>{</c-> <c- n>f</c-><c- p>(</c-><c- n>e</c-><c- p>);</c-> <c- p>}</c->
</pre>
       <p>Marking the template definition <code class="highlight"><c- kr>inline</c-></code> would mean that the intended declaration for <code class="highlight"><c- n>g</c-></code> would need to be provided as the best candidate at the points-of-instantiation for <code class="highlight"><c- n>f</c-><c- o>&amp;</c-><c- n>lt</c-><c- p>;</c-><c- n>E</c-><c- o>&amp;</c-><c- n>gt</c-><c- p>;</c-></code>.</p>
       <p>The issue initially points out that this use of the <code class="highlight"><c- kr>inline</c-></code> keyword does not match a view that <code class="highlight"><c- kr>inline</c-></code> is essentially an ODR tool to allow multiple definitions (as opposed to a way to indicate desire for inlining) and proposed that <code class="highlight"><c- k>extern</c-> <c- k>template</c-></code> merely has the effect of suppressing definitions in terms of linkage (regardless of the <code class="highlight"><c- kr>inline</c-></code> keyword). Such a change would affect the usability of the feature for user intent that falls within the latter two options above.</p>
       <p>I am not sure if CWG is asking EWG a specific question other than the general "we do not believe this is a wording or obvious consistency issue; is this an issue in terms of design?"</p>
       <p><b>Meeting:</b></p>
       <p>Hubert <a href="https://lists.isocpp.org/ext/2020/05/13799.php"><span>forked the thread on the reflector</span></a>. Might want the education SG to take a look, or might want a paper.</p>
       <p><b>Meeting 2020-10-28</b>: Inbal will try to put together the wording, to prove / disprove whether this is a defect.</p>
      <td valign="top">
       <p>♻️</p>
     <tr>
      <td valign="top">
       <p>Lib</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-lwg2432">[LWG2432]</a></p>
      <td valign="top">
       <p>initializer_list assignability</p>
      <td valign="top">
       <p>std::initializer_list::operator= [support.initlist] is horribly broken and it needs deprecation:</p>
       <p><br></p>
       <p>std::initializer_list&lt;foo> a = {{1}, {2}, {3}};</p>
       <p>a = {{4}, {5}, {6}};</p>
       <p>// New sequence is already destroyed.</p>
       <p><br></p>
       <p>Assignability of initializer_list isn’t explicitly specified, but most implementations supply a default assignment operator. I’m not sure what [description] says, but it probably doesn’t matter.</p>
       <p><br></p>
       <p><b>Proposed resolution:</b></p>
       <p><br></p>
       <p>Edit [support.initlist] p1, class template initializer_list synopsis, as indicated:</p>
       <p><br></p>
       <p>namespace std {</p>
       <p>  template&lt;class E> class initializer_list {</p>
       <p>  public:</p>
       <p>    […]</p>
       <p>    constexpr initializer_list() noexcept;</p>
       <p></p>
       <p>    initializer_list(const initializer_list&amp;) = default;</p>
       <p>    initializer_list(initializer_list&amp;&amp;) = default;</p>
       <p>    initializer_list&amp; operator=(const initializer_list&amp;) = delete;</p>
       <p>    initializer_list&amp; operator=(initializer_list&amp;&amp;) = delete;</p>
       <p></p>
       <p>    constexpr size_t size() const noexcept;</p>
       <p>    […]</p>
       <p>  };</p>
       <p>  […]</p>
       <p>}</p>
       <p><br></p>
       <p><span><a href="http://wiki.edg.com/bin/view/Wg21cologne/LWGTelecon-2014-12-18">LWG telecon</a></span> appears to want a language change to disallow assigning a braced-init-list to an std::initializer_list but still permit move assignment of std::initializer_list objects. That is,</p>
       <p><br></p>
       <p>auto il1 = {1,2,3};</p>
       <p>auto il2 = {4,5,6};</p>
       <p>il1 = {7,8,9}; // currently well-formed but dangles immediately; should be ill-formed</p>
       <p>il1 = std::move(il2); // currently well-formed and should remain so</p>
       <p><br></p>
       <p><b>Meeting:</b> Proposed resolution:</p>
<pre class="highlight"><c- n>initializer_list</c-><c- p>(</c-><c- k>const</c-> <c- n>initializer_list</c-><c- o>&amp;</c-><c- p>)</c-> <c- o>=</c-> <c- k>default</c-><c- p>;</c->
<c- n>initializer_list</c-><c- p>(</c-><c- n>initializer_list</c-><c- o>&amp;&amp;</c-><c- p>)</c-> <c- o>=</c-> <c- k>default</c-><c- p>;</c->
<c- p>[[</c-><c- n>deprecated</c-><c- p>]]</c-> <c- n>initializer_list</c-><c- o>&amp;</c-> <c- k>operator</c-><c- o>=</c-><c- p>(</c-><c- k>const</c-> <c- n>initializer_list</c-><c- o>&amp;</c-><c- p>)</c-> <c- o>=</c-> <c- k>default</c-><c- p>;</c->
<c- p>[[</c-><c- n>deprecated</c-><c- p>]]</c-> <c- n>initializer_list</c-><c- o>&amp;</c-> <c- k>operator</c-><c- o>=</c-><c- p>(</c-><c- n>initializer_list</c-><c- o>&amp;&amp;</c-><c- p>)</c-> <c- o>=</c-> <c- k>default</c-><c- p>;</c->
</pre>
       <p>SF F N A SA</p>
       <p>0 3 12 0 0</p>
       <p>JF <a href="https://lists.isocpp.org/lib-ext/2020/05/15334.php"><span>emailed LEWG</span></a>, to see if they have an opinion, no feedback. Asked LEWG chairs to schedule for a telecon.</p>
       <p><span><a href="https://lists.isocpp.org/lib/2020/10/17760.php">LWG discussed</a></span> priority.</p>
      <td valign="top">
       <p>♻️</p>
     <tr>
      <td valign="top">
       <p>Lib</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-lwg2813">[LWG2813]</a></p>
      <td valign="top">
       <p>std::function should not return dangling references</p>
      <td valign="top">
       <p>If a std::function has a reference as a return type, and that reference binds to a prvalue returned by the callable that it wraps, then the reference is always dangling. Because any use of such a reference results in undefined behaviour, the std::function should not be allowed to be initialized with such a callable. Instead, the program should be ill-formed.</p>
       <p><br></p>
       <p>A minimal example of well-formed code under the current standard that exhibits this issue:</p>
       <p><br></p>
       <p>int main()  {</p>
       <p>  std::function&lt;const int&amp;()> F([]{ return 42; });</p>
       <p>  int x = F(); // oops!</p>
       <p>}</p>
       <p><br></p>
       <p><b>Proposed resolution:</b></p>
       <p><br></p>
       <p>Add a second paragraph to the remarks section of 20.14.16.2.1 [func.wrap.func.con]:</p>
       <p><br></p>
       <p>template&lt;class F> function(F f);</p>
       <p>-7- Requires: F shall be CopyConstructible.</p>
       <p>-8- Remarks: This constructor template shall not participate in overload resolution unless</p>
       <ul>
        <li><span></span>F is Lvalue-Callable (20.14.16.2 [func.wrap.func]) for argument types ArgTypes... and return type R, and<br> 
        <li><span></span>If R is type "reference to T" and INVOKE(ArgTypes...) has value category V and type U:<br> 
        <ul>
         <li><span></span>V is a prvalue, U is a class type, and T is not reference-related (9.4.3 [dcl.init.ref]) to U, and<br> 
         <li><span></span>V is an lvalue or xvalue, and either U is a class type or T is reference-related to U.<br> 
        </ul>
       </ul>
       <p>[…]</p>
       <p><br></p>
       <p><b>Tim:</b> LWG in Batavia 2018 would like a way to detect when the initialization of a reference would bind it to a temporary. This requires compiler support, since there’s no known way in the current language to do so reliably in the presence of user-defined conversions (see thread starting at <a href="https://lists.isocpp.org/lib/2017/07/3256.php"><span>https://lists.isocpp.org/lib/2017/07/3256.php</span></a>).</p>
       <p><br></p>
       <p><b>Meeting:</b> </p>
       <p>Tim wrote <a href="https://wg21.link/p2255"><span>p2255</span></a> to address this.</p>
       <p>Ville thinks there should be an analysis of alternative approaches.</p>
       <p>Also see <a href="http://wg21.link/P0932"><span>P0932</span></a>.</p>
      <td valign="top">
       <p>♻️</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg728">[CWG728]</a></p>
      <td valign="top">
       <p>Restrictions on local classes</p>
      <td valign="top">
       <p>Now that the restriction against local classes being used as template arguments has been lifted, they are more useful, yet they are still crippled. For some reason or oversight, the restriction against local classes being templates or having member templates was not lifted. Allowing local classes to have member templates facilitates generic programming (the reason for lifting the other restriction), especially when it comes to the visitor-pattern (see the boost::variant documentation and the following example) as implemented in boost and the boost::MPL library (since functors have to be template classes in mpl, and higher-order functors have to have member templates to be useful). A local class with a member template would allow this desirable solution:</p>
       <p>    #include &lt;boost/variant.hpp></p>
       <p>    int main() {</p>
       <p>      struct times_two_generic: public boost::static_visitor&lt;> {</p>
       <p>        template &lt;typename T> void operator()(T&amp; operand) const {</p>
       <p>            operand += operand;</p>
       <p>        }</p>
       <p>      };</p>
       <p>      std::vector&lt;boost::variant&lt;int, std::string>> vec;</p>
       <p>      vec.push_back(21);</p>
       <p>      vec.push_back("hello ");</p>
       <p>      times_two_generic visitor;</p>
       <p>      std::for_each(vec.begin(), vec.end(), boost::apply_visitor(visitor));</p>
       <p>    }</p>
       <p>Is there any compelling reason not to allow this code? Is there any compelling reason not to allow local classes to be templates, have friends, or be able to define their static data members at function scope? Wouldn’t this symmetry amongst local and non-local classes make the language more appealing and less embarrassing?</p>
       <p>Also see <a href="http://wg21.link/p2044"><span>p2044</span></a>, seen by EWGI in Prague and requested to be merged with <a href="http://wg21.link/P1988"><span>P1988</span></a>, and implementors queried.</p>
       <p><span><a href="https://isocpp.org/files/papers/D2044R2.pdf">The current paper draft</a></span> addresses all of this.</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020"><span>notes</span></a>)</p>
       <p>Some folks unsure that we should do anything here. Revisit the resolution with P2044.</p>
       <p>Extension issues are a closed status on the issues list, like NAD Future was for LWG I find it helpful to have a status that says EWG may still be considering it.</p>
       <p>Suggest closing as Not A Defect because we have significant implementation concerns, but we’ll explore the design space in P2044. All in favor.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg794">[CWG794]</a></p>
      <td valign="top">
       <p>Base-derived conversion in member type of pointer-to-member conversion</p>
      <td valign="top">
       <p>Related to <a href="http://wg21.link/cwg170"><span>CWG 170</span></a>, drafting by Clark seems unlikely. This is section 2.1 of Jeff Snyder’s <a href="http://wg21.link/P0149R0"><span>P0149R0</span></a>, which was approved by EWG, <a href="http://wiki.edg.com/bin/view/Wg21oulu/P0149R0"><span>4 years ago</span></a>, waiting for wording.</p>
       <p>JF reached out to Jeff. Did wording with Jens, main blocker is lack of implementation.</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020"><span>notes</span></a>) Suggest closing as Not A Defect because we have implementation uncertainties, but we’ll explore the design space in P0149. ABI group will discuss. All in favor.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg900">[CWG900]</a></p>
      <td valign="top">
       <p>Lifetime of temporaries in range-based for</p>
      <td valign="top">
       <p>// some function</p>
       <p>  std::vector&lt;int> foo();</p>
       <p>  // correct usage</p>
       <p>  auto v = foo();</p>
       <p>  for( auto i : reverse(v) ) { std::cout &lt;&lt; i &lt;&lt; std::endl; }</p>
       <p>  // problematic usage</p>
       <p>  for( auto i : reverse(foo()) ) { std::cout &lt;&lt; i &lt;&lt; std::endl; }</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020"><span>notes</span></a>, also <a href="https://wiki.edg.com/bin/view/Wg21rapperswil2014/EvolutionWorkingGroup"><span>discussed in Rapperswil 2014</span></a>) Suggest closing as Not A Defect because it’s a change which might have effects on existing code (might cause bugs), and might need to change more than just range-based loops. See <a href="http://wg21.link/p0614"><span>p0614</span></a>, <a href="http://wg21.link/p0577"><span>p0577</span></a>, <a href="http://wg21.link/p0936"><span>p0936</span></a>, <a href="http://wg21.link/p1179"><span>p1179</span></a>. We’ll explore the design space in a separate paper, Herb circled back with Nico on this, might write a paper. All in favor.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg944">[CWG944]</a></p>
      <td valign="top">
       <p>reinterpret_cast for all types with the same size and alignment</p>
      <td valign="top">
       <p>During the discussion of issue <a href="http://wg21.link/cwg799"><span>799</span></a>, which specified the result of using reinterpret_cast to convert an operand to its own type, it was observed that it is probably reasonable to allow reinterpret_cast between any two types that have the same size and alignment.</p>
       <p>Additional note, April, 2015: It has been suggested that this question may more properly be the province of EWG, especially in light of discussions during the resolution of issue <a href="http://wg21.link/cwg330"><span>330</span></a>. The priority has been deleted to allow CWG to reconsider its status.</p>
       <p>Rationale (May, 2015): CWG agreed that this question should be considered from a language design perspective and is thus being referred to EWG.</p>
       <p>Suggest rejection: we chose to add std::bit_cast to provide exactly this functionality instead of extending reinterpret_cast.</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020"><span>notes</span></a>) Suggest closing as Not A Defect. bit_cast addresses some of the usecases this issue might cover. We’d want separate papers to support other usescases, but have nothing outstanding at the moment. All in favor.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1008">[CWG1008]</a></p>
      <td valign="top">
       <p>Querying the alignment of an object</p>
      <td valign="top">
       <p><span><a href="https://godbolt.org/z/_SN8iF">https://godbolt.org/z/_SN8iF</a></span></p>
       <ul>
        <li><span></span>GCC already implements this extension without issuing a warning
        <li><span></span>Clang and EDG implement this extension for gcc compatibility, with a warning
        <li><span></span>MSVC does not yet implement this feature
       </ul>
       <p>Quick example using ‘auto’ illustrates why we might want this capability for objects as well as types.</p>
       <p>Principle of least astonishment suggests it is surprising for sizeof and alignof to behave differently in this regard.</p>
       <p>Recommend shipping this straight to core as soon as we can find a wording champion.</p>
       <p>We need to discuss with WG14.</p>
       <p>Questions for EWG to answer before forwarding:</p>
       <ul>
        <li><span></span>Should this be a unary operator, like sizeof, so "alignof x" is valid? Or should it be like typeid, where parens are required?
        <li><span></span>What would this mean? Is it the alignment of the type of the object? Or the compiler’s best guess of the alignment of the expression itself? Should it take into account any facts that are known about the expression other than its type? If so, which ones? (For example, if applied to an expression x or e.x and x is declared with an <code class="highlight"><c- k>alignas</c-></code> attribute, is that value returned?)
       </ul>
       <p>This needs a design paper rather than going straight to core.</p>
       <p><span><a href="https://godbolt.org/z/TeVA9T">https://godbolt.org/z/TeVA9T</a></span> GCC seems to report the alignment of the object not just of decltype(object).</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020"><span>notes</span></a>, also <a href="https://wiki.edg.com/bin/view/Wg21rapperswil2014/EvolutionWorkingGroup"><span>discussed in Rapperswil 2014</span></a>) Suggest closing as Not A Defect, the design is complex especially around alignment of object versus type. Invite a paper, Inbal will pitch in, Alidair can collaborate. All in favor.</p>
       <p>Inbal’s paper: <a href="http://wg21.link/P2152R0"><span>P2152R0</span></a></p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1077">[CWG1077]</a></p>
      <td valign="top">
       <p>Explicit specializations in non-containing namespaces</p>
      <td valign="top">
       <p>The current wording of 9.8.1.2 [namespace.memdef] and 13.9.3 [temp.expl.spec] requires that an explicit specialization be declared either in the same namespace as the template or in an enclosing namespace. It would be convenient to relax that requirement and allow the specialization to be declared in a non-enclosing namespace to which one or more if the template arguments belongs.</p>
       <p>Additional note, April, 2015: See EWG issue <a href="http://wg21.link/cwg48"><span>48</span></a>.</p>
       <p>Might allow us to revert <a href="http://wg21.link/cwg2061"><span>DR2061</span></a> and all the horribleness that created and described in <a href="http://wg21.link/p1701"><span>p1701</span></a>.  The problem 1077 addresses is the motivating factor in dr2061.</p>
       <p>Also see <a href="http://wg21.link/cwg2370"><span>CWG 2370</span></a>.</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020"><span>notes</span></a>) Suggest closing as Not A Defect. See <a href="http://wg21.link/p0665"><span>p0665</span></a>, <a href="http://wiki.edg.com/bin/view/Wg21rapperswil2018/P0665R1-Rap18"><span>minutes</span></a>. Continue under p0665 or a forked version of it. All in favor.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1433">[CWG1433]</a></p>
      <td valign="top">
       <p><i>trailing-return-type</i> and point of declaration</p>
      <td valign="top">
       <p>template &lt;class T> T list(T x);</p>
       <p>    template &lt;class H, class ...T></p>
       <p>    auto list(H h, T ...args) -> decltype(list(args...)); // list isn’t in scope in its own <i>trailing-return-type</i></p>
       <p>    auto list3 = list(1, 2, 3);</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes</span></a>, also <a href="https://wiki.edg.com/bin/view/Wg21rapperswil2014/EvolutionWorkingGroup"><span>discussed in Rapperswil 2014</span></a>) there might be compiler divergence according to Daveed. Suggest closing as Not A Defect, it would be tricky to change behavior without ambiguity. "Fixing" this would break existing code that relies on seeing only previous declarations. No objection to unanimous consent.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1451">[CWG1451]</a></p>
      <td valign="top">
       <p>Objects with no linkage in non-type template arguments</p>
      <td valign="top">
       <p>According to 13.4.2 [temp.arg.nontype] paragraph 1 bullet 3, only objects with linkage can be used to form non-type template arguments. Is this restriction still needed? It would be convenient to use block-scope objects as template arguments.</p>
       <p>Resolved by <a href="http://wg21.link/N4268"><span>N4268</span></a>.</p>
       <p>The following is valid:</p>
       <p>template &lt;int *> struct A;</p>
       <p>auto f() {</p>
       <p>  static int x;</p>
       <p>  A&lt;&amp;x> *ap = nullptr;</p>
       <p>  return ap;</p>
       <p>}</p>
       <p>There is no longer any linkage restriction. There is a restriction on storage duration, which seems reasonable (you can use the address of a local static variable but not of a local automatic variable as a non-type template argument).</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes</span></a>, also <a href="https://wiki.edg.com/bin/view/Wg21rapperswil2014/EvolutionWorkingGroup"><span>discussed in Rapperswil 2014</span></a>) Suggest closing as Not A Defect. Addressed by N4268. No objection to unanimous consent.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1469">[CWG1469]</a></p>
      <td valign="top">
       <p>Omitted bound in array <i>new-expression</i></p>
      <td valign="top">
       <p>The syntax for noptr-new-declarator in 7.6.2.7 [expr.new] paragraph 1 requires an expression, even though the bound could be inferred from a braced-init-list initializer. It is not clear whether 9.4.1 [dcl.init.aggr] paragraph 4, An array of unknown size initialized with a brace-enclosed initializer-list containing n initializer-clauses, where n shall be greater than zero, is defined as having n elements (9.3.3.4 [dcl.array]).</p>
       <p>should be considered to apply to the new-type-id variant, e.g.,</p>
       <p>  new (int[]){1, 2, 3}</p>
       <p>This was addressed by <a href="http://wg21.link/p1009"><span>p1009</span></a></p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes</span></a>) Suggest closing as Not A Defect. Addressed by P1009. No objection to unanimous consent.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1555">[CWG1555]</a></p>
      <td valign="top">
       <p>Language linkage and function type compatibility</p>
      <td valign="top">
       <p>Currently function types with different language linkage are not compatible, and 7.6.1.2 [expr.call] paragraph 1 makes it undefined behavior to call a function via a type with a different language linkage. These features are generally not enforced by most current implementations (although some do) between functions with C and C++ language linkage. Should these restrictions be relaxed, perhaps as conditionally-supported behavior?</p>
       <p>Somewhat related to CWG1463.</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes</span></a>) no strong consensus at the moment, Erich Keane brought this up with SG12 Undefined Behavior. <a href="https://lists.isocpp.org/sg12/2020/05/0905.php"><span>Long discussion</span></a>, will need to revisit, need a paper.</p>
       <p><b>Meeting Oct 22nd 2020:</b> will need a volunteer to write a paper, but the wording in the standard is unambiguous, and we have existence proof of platforms which use different calling conventions between C and C++. However many major compilers have chosen to ignore this. Not a defect, but we welcome a paper to change the status quo. No objection to unanimous consent.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1643">[CWG1643]</a></p>
      <td valign="top">
       <p>Default arguments for template parameter packs</p>
      <td valign="top">
       <p>Although 13.2 [temp.param] paragraph 9 forbids default arguments for template parameter packs, allowing them would make some program patterns easier to write. Should this restriction be removed?</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes</span></a>) Suggest closing as Not A Defect. Interesting design space, but needs a paper, see N3416. No objection to unanimous consent.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1864">[CWG1864]</a></p>
      <td valign="top">
       <p>List-initialization of array objects</p>
      <td valign="top">
       <p>The resolution of issue <a href="http://wg21.link/cwg1467"><span>1467</span></a> now allows for initialization of aggregate classes from an object of the same type. Similar treatment should be afforded to array aggregates.</p>
       <p>See recent discussion on allowing 'auto x[] = {1, 2, 3};' -- this topic came up there. The two questions can be answered independently, but some consider them to be related.</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes</span></a>) Suggest closing as Not A Defect. Fixing anything in this space would require a paper which considers the entire design space, Timur might be interested in this. No objection to unanimous consent.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1871">[CWG1871]</a></p>
      <td valign="top">
       <p>Non-identifier characters in <i>ud-suffix</i></p>
      <td valign="top">
       <p>JF forwarded to SG16 Unicode given their work on TR31. Tracked on <a href="https://github.com/sg16-unicode/sg16/issues/61"><span>GitHub</span></a>. SG16 reviewed D1949R3, still needs wording changes. Discussed at <a href="https://github.com/sg16-unicode/sg16-meetings#april-22nd-2020"><span>the April 22nd SG16 telecon</span></a>.</p>
       <p><b>SG16 Poll:</b> Is there any objection to unanimous consent for recommending rejection of this proposal? No objection to unanimous consent.</p>
       <p><b>EWG Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes 2020-04-15</span></a>, <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-07-May-2020"><span>notes 2020-05-07</span></a>) Suggest closing as Not A Defect. No objection to unanimous consent.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1876">[CWG1876]</a></p>
      <td valign="top">
       <p>Preventing explicit specialization</p>
      <td valign="top">
       <p>A desire has been expressed for a mechanism to prevent explicitly specializing a given class template, in particular std::initializer_list and perhaps some others in the standard library. It is not clear whether simply adding a prohibition to the description of the templates in the library clauses would be sufficient or whether a core language mechanism is required.</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020"><span>notes</span></a>) Suggest closing as Not A Defect. No objection to unanimous consent. This could be a language feature, would need library usecase examples.</p>
       <p><b>Poll:</b> we are interested in such a paper SF 2 F 13 N 6 A 1 SA 0</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1915">[CWG1915]</a></p>
      <td valign="top">
       <p>Potentially-invoked destructors in non-throwing constructors</p>
      <td valign="top">
       <p>Since the base class constructor is non-throwing, the deleted base class destructor need not be referenced.</p>
       <p>There’s a typo in the issues list here: it should say "Since the <em>derived</em> class constructor is non-throwing, the deleted base class destructor need not be referenced."</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020"><span>notes 2020-04-23</span></a>) the proposed wording changes the implementation leeway in two-phase unwinding, which breaks some existing ABIs. We would need  a paper to explore this further. Suggest closing as Not A Defect. No objection to unanimous consent.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1923">[CWG1923]</a></p>
      <td valign="top">
       <p>Lvalues of type void</p>
      <td valign="top">
       <p>There does not seem to be any significant technical obstacle to allowing a void* pointer to be dereferenced, and that would avoid having to use weighty circumlocutions when casting to a reference to an object designated by such a pointer.</p>
       <p>Might consider this a duplicate of the discussion on "regular void".</p>
       <p>JF reached out to Matt. He has an implementation in clang. Needs to update the paper. Might need a volunteer to present. Daveed would be interested in presenting.</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020"><span>notes 2020-04-23</span></a>) Suggest closing as Not A Defect. Explore under the “regular void” umbrella. No objection to unanimous consent.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1934">[CWG1934]</a></p>
      <td valign="top">
       <p>Relaxing <i>exception-specification</i> compatibility requirements</p>
      <td valign="top">
       <p>According to 14.5 [except.spec] paragraph 4,</p>
       <p><br></p>
       <p>If any declaration of a function has an exception-specification that is not a noexcept-specification allowing all exceptions, all declarations, including the definition and any explicit specialization, of that function shall have a compatible exception-specification.</p>
       <p><br></p>
       <p>This seems excessive for explicit specializations, considering that paragraph 6 applies a looser requirement for virtual functions:</p>
       <p><br></p>
       <p>If a virtual function has an exception-specification, all declarations, including the definition, of any function that overrides that virtual function in any derived class shall only allow exceptions that are allowed by the exception-specification of the base class virtual function.</p>
       <p><br></p>
       <p>The rule in paragraph 3 is also problematic in regard to explicit specializations of destructors and defaulted special member functions, as the implicit exception-specification of the template member function cannot be determined.</p>
       <p><br></p>
       <p>There is also a related problem with defaulted special member functions and exception-specifications. According to 9.5.2 [dcl.fct.def.default] paragraph 3,</p>
       <p><br></p>
       <p>If a function that is explicitly defaulted has an explicit exception-specification that is not compatible (14.5 [except.spec]) with the exception-specification on the implicit declaration, then</p>
       <ul>
        <li><span></span>if the function is explicitly defaulted on its first declaration, it is defined as deleted;
        <li><span></span>otherwise, the program is ill-formed.<br> 
       </ul>
       <p>This rule precludes defaulting a virtual base class destructor or copy/move functions if the derived class function will throw an exception not allowed by the implicit base class member function.</p>
       <p><br></p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020"><span>notes 2020-04-23</span></a>) JF will work with Mike to update wording to C++20. Will revisit.</p>
       <p>From Mike: This issue is NAD since we eliminated typed exception-specifications. The current wording, dealing only with noexcept(true) and noexcept(false), does not have this issue. Will remove “extension” status.</p>
       <p><b>Meeting:</b> no objection to CWG taking it back, and marking it as NAD.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1957">[CWG1957]</a></p>
      <td valign="top">
       <p>decltype(auto) with direct-list-initialization</p>
      <td valign="top">
       <p>Paper <a href="http://wg21.link/N3922"><span>N3922</span></a> changed the rules for deduction from a braced-init-list containing a single expression in a direct-initialization context. Should a corresponding change be made for decltype(auto)? E.g.,</p>
       <p>  auto x8a = { 1 };           // decltype(x8a) is std::initializer_list&lt;int></p>
       <p>  decltype(auto) x8d = { 1 }; // ill-formed, a braced-init-list is not an expression</p>
       <p>  auto x9a{ 1 };              // decltype(x9a) is int</p>
       <p>  decltype(auto) x9d{ 1 };    // decltype(x9d) is int</p>
       <p>See also issue <a href="http://wg21.link/cwg1467"><span>1467</span></a>, which also effectively ignores braces around a single expression, this change would be parallel to that one, even though the primary motivation for delctype(auto) is in the return type of a forwarding function, where direct-initialization does not apply.</p>
       <p><br></p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020"><span>notes 2020-04-23</span></a>) Suggest closing as Not A Defect. This would be a language change, it’s unclear that we want to make such a change. It would require a paper. Mike Spertus is writing a paper with some overlap, will cover this as well. No objection to unanimous consent.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg2111">[CWG2111]</a></p>
      <td valign="top">
       <p>Array temporaries in reference binding</p>
      <td valign="top">
       <p>The current wording of the Standard appears to permit code like</p>
<pre class="highlight"><c- b>void</c-> <c- nf>f</c-><c- p>(</c-><c- k>const</c-> <c- b>char</c-> <c- p>(</c-><c- o>&amp;</c-><c- p>)[</c-><c- mi>10</c-><c- p>]);</c->
<c- b>void</c-> <c- nf>g</c-><c- p>()</c-> <c- p>{</c->
  <c- n>f</c-><c- p>(</c-><c- s>"123"</c-><c- p>);</c->
  <c- n>f</c-><c- p>({</c-><c- sc>'a'</c-><c- p>,</c-><c- sc>'b'</c-><c- p>,</c-><c- sc>'c'</c-><c- p>,</c-><c- sc>'\0'</c-><c- p>});</c->
<c- p>}</c->
</pre>
       <p>creating a temporary array of ten elements and binding the parameter reference to it. This is controversial and should be reconsidered. (See issues <a href="http://wg21.link/cwg1058"><span>1058</span></a> and <a href="http://wg21.link/cwg1232"><span>1232</span></a>.)</p>
       <p><br></p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020"><span>notes 2020-04-23</span></a>) JF digging more, talking to Richard about this.</p>
       <p>Somewhat related to <a href="http://wg21.link/P2174"><span>P2174</span></a> compound literals.</p>
       <p>Would be very strange if</p>
       <p><span>  </span><code class="highlight"><c- k>const</c-> <c- b>char</c-> <c- p>(</c-><c- o>&amp;</c-><c- n>amp</c-><c- p>;</c-><c- o>&amp;</c-><c- n>amp</c-><c- p>;</c-><c- n>x</c-><c- p>)[</c-><c- mi>10</c-><c- p>]</c-> <c- o>=</c-> <c- p>{</c-><c- sc>'a'</c-><c- p>,</c-> <c- sc>'b'</c-><c- p>,</c-> <c- sc>'c'</c-><c- p>};</c-></code></p>
       <p>... were invalid but ...</p>
       <p><span>  </span><code class="highlight"><c- k>const</c-> <c- b>char</c-> <c- n>x</c-><c- p>[</c-><c- mi>10</c-><c- p>]</c-> <c- o>=</c-> <c- p>{</c-><c- sc>'a'</c-><c- p>,</c-> <c- sc>'b'</c-><c- p>,</c-> <c- sc>'c'</c-><c- p>};</c-></code></p>
       <p><span>  </span><code class="highlight"><c- k>const</c-> <c- b>char</c-> <c- p>(</c-><c- o>&amp;</c-><c- n>amp</c-><c- p>;</c-><c- o>&amp;</c-><c- n>amp</c-><c- p>;</c-><c- n>x</c-><c- p>)[</c-><c- mi>3</c-><c- p>]</c-> <c- o>=</c-> <c- p>{</c-><c- sc>'a'</c-><c- p>,</c-> <c- sc>'b'</c-><c- p>,</c-> <c- sc>'c'</c-><c- p>};</c-></code></p>
       <p>... were both OK. Maybe either we should allow the trailing elements to be zeroed in general (the status quo), or not (a major breaking change). Which means we should reject the issue on consistency grounds. The general rule is that if</p>
       <p><span>  </span>T &amp;&amp;r = init;</p>
       <p>... can’t bind directly, we create a temporary initialized as if with</p>
       <p><span>  </span>T r = init;</p>
       <p>... and bind to that. (And similarly for const references.)</p>
       <p>Another question: Do we want to support (T){inits} as a synonym for T{inits}?</p>
       <p><br></p>
       <p><b>Meeting Oct 22nd 2020:</b> Note that the issue itself is defective, and <code class="highlight"><c- n>f</c-><c- p>(</c-><c- s>"123"</c-><c- p>)</c-></code> isn’t valid.</p>
       <p>CWG2352 references p1358, and was resolved, leading us to believe that this is now mainstream and not controversial. Not a defect. No objection to unanimous consent.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg2125">[CWG2125]</a></p>
      <td valign="top">
       <p>Copy elision and comma operator</p>
      <td valign="top">
       <p>Currently, _N4750_.15.8 [class.copy] paragraphs 31-32 apply only to the name of a local variable in determining whether a return expression is a candidate for copy elision or move construction. Would it make sense to extend that to include the right operand of a comma operator?</p>
       <p><br></p>
       <p>X f() {</p>
       <p>  X x;</p>
       <p>  return (0, x);</p>
       <p>}</p>
       <p><br></p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020"><span>notes 2020-04-23</span></a>) Consider expanding to other places that expand bit-field-ness such as return b ? throw : x;. Suggest closing as Not A Defect. Will need a paper to address, no current volunteer for this. No objection to unanimous consent.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg2132">[CWG2132]</a></p>
      <td valign="top">
       <p>Deprecated default generated copy constructors</p>
      <td valign="top">
       <p>EWG has indicated that they are not currently in favor of removing the implicitly declared defaulted copy constructors and assignment operators that are eprecated in _N4750_.15.8 [class.copy] paragraphs 7 and 18. Should this deprecation be removed?</p>
       <p>Related: discussing under <a href="http://wg21.link/p2139"><span>p2139</span></a> deprecations.</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-29-Apr-2020"><span>note 2020-04-29</span></a>) Suggest closing as Not A Defect. No objection to unanimous consent. We either want to remove entirely, or un-deprecate. This will need a paper, Ville will talk with Alisdair about forking the topic from p2139.</p>
      <td valign="top">
       <p>NAD</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg914">[CWG914]</a></p>
      <td valign="top">
       <p>Value-initialization of array types</p>
      <td valign="top">
       <p>Although value-initialization is defined for array types and the () initializer is permitted in a mem-initializer naming an array member of a class, the syntax T() (where is an array type) is explicitly forbidden by 7.6.1.3 [expr.type.conv] paragraph 2. This is inconsistent and the syntax should be permitted.</p>
       <p>Rationale (July, 2009): The CWG was not convinced of the utility of this extension, especially in light of questions about handling the lifetime of temporary arrays. This suggestion needs a proposal and analysis by the EWG before it can be considered by the CWG.</p>
       <p>This has become a more severe inconsistency after we adopted Ville’s <a href="http://wg21.link/P0960"><span>P0960</span></a> for C++20. Now it’s not only () that has this weird special-case restriction, it’s (a, b, c) too:</p>
       <p>using X = int[];</p>
       <p>X x{1, 2, 3}; // ok, int[3]</p>
       <p>X y(1, 2, 3); // ok, int[3]</p>
       <p>f(X{1, 2, 3}); // ok, int[3] temporary</p>
       <p>f(X(1, 2, 3)); // error</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020"><span>notes</span></a>) it is a defect, need a paper. David Stone trying to find a volunteer to write said paper. All in favor.</p>
      <td valign="top">
       <p>Paper needed</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1463">[CWG1463]</a></p>
      <td valign="top">
       <p>extern "C" alias templates</p>
      <td valign="top">
       <p>Currently 13 [temp] paragraph 4 forbids any template from having C linkage. Should alias templates be exempt from this prohibition, since they do not have any linkage?</p>
       <p>Additional note, April, 2013: It was suggested (see messages 23364 through 23367) that relaxing this restriction for alias templates could provide a way of addressing the long-standing lack of a way of specifying a language linkage for a dependent function type (see issue <a href="http://wg21.link/cwg13"><span>13</span></a>). The priority was deleted to allow CWG to consider the implications of that potential application of the facility.</p>
       <p>We should either have some way to express a dependent function type with C language linkage (and should accept <a href="http://wg21.link/cwg1555"><span>1555</span></a> below) or we should remove the notion that C language linkage (or not) is part of the function type at all. (Apparently some targets used it; are they still in use? EDG probably knows.)</p>
       <p>Actively discussed on <a href="http://lists.isocpp.org/core/2020/04/8823.php"><span>CWG reflector</span></a>.</p>
       <p><br></p>
       <p><b>Davis’ interpretation of CWG discussion</b>:</p>
       <p>I don’t speak for Core, of course, but my (Evolutionary) thoughts are those given (last) in the message to which you replied: neither the wording nor the apparent intent of [temp.pre]/6’s restrictions on C linkage for templates make any sense.  Since templates (and explicit specializations) can’t have C linkage of the name-mangling variety (which the standard calls language linkage of a (function) name) but can have C linkage of the calling-convention variety (which the standard calls language linkage of a (function) type), extern "C" should grant them the latter and not the former with no error.  This has certain obvious applications involving C APIs with callbacks.  (Put differently, CWG13 shouldn’t have been rejected; it appears to have gotten bogged down in questions of syntax, but we have an adequate syntactic workaround that we merely have to permit.)</p>
       <p>CWG1463 asks for a (very) proper subset of the above: merely that extern "C" be allowed to apply to alias templates (claiming incorrectly that they have no name with linkage at all).  I consider it more relevant (and more productive) to talk about whether entities have names with language linkage than with the ordinary kind.</p>
       <p>The Core reflector discussion (which seems to have finished for the moment) also touched on the case where "the same" function template is declared with two different language linkages for its type, but the only relevant Evolution input there would be a decision to go the opposite way and forbid function templates from having types with C language linkage entirely.  (They currently can, but it’s mostly or entirely useless.)</p>
       <p>If (for CWG1555, also on your list) the rules about language linkage of (function) types are sufficiently relaxed, then CWG1463 may be moot (and my extension of it with it), but that seems unlikely given Hubert’s recent identification of a case where they matter.</p>
       <p><br></p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes 2020-04-15</span></a>, <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG22-Oct-2020"><span>notes 2020-10-22</span></a>, also <a href="https://wiki.edg.com/bin/view/Wg21rapperswil2014/EvolutionWorkingGroup"><span>discussed in Rapperswil 2014</span></a>) We agree that this is an issue. extern “C” on a template should only affect calling convention, and not the mangling. Davis and Hubert volunteer to write a paper. Unanimous consent.</p>
      <td valign="top">
       <p>Paper needed</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1790">[CWG1790]</a></p>
      <td valign="top">
       <p>Ellipsis following function parameter pack</p>
      <td valign="top">
       <p>Although the current wording permits an ellipsis to immediately follow a function parameter pack, it is not clear that the &lt;cstdarg> facilities permit access to the ellipsis arguments.</p>
       <p>The problem here (which is not explained in the issue) is: how do you supply the name of the last parameter before the ellipsis to va_start? You can’t put the name of a pack there (it wouldn’t be expanded) and there’s no way to name the last element of the pack (nor to deal with the case where the pack is empty).</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes</span></a>) 3 options: fix wording around “last parameter”, remove facility entirely (either va_start or function declarator), try to invent a language facility. JF <a href="https://lists.isocpp.org/ext/2020/04/13346.php"><span>emailed EWG</span></a> to see if anyone has a strong preference, or if we should send back to CWG to fix wording, long discussion.</p>
       <p><b>Michael Spertus:</b> I am willing to commit to including and analysis on this in an upcoming paper on parameter packs.</p>
       <p>JF followed up with Michael and Barry, no response.</p>
      <td valign="top">
       <p>Paper needed</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg1962">[CWG1962]</a></p>
      <td valign="top">
       <p>Type of __func__</p>
      <td valign="top">
       <p>Two questions have arisen regarding the treatment of the type of the __func__ built-in variable. First, some implementations accept</p>
       <p>  void f() {</p>
       <p>    typedef decltype(__func__) T;</p>
       <p>    T x = __func__;</p>
       <p>  }</p>
       <p>even though T is specified to be an array type.</p>
       <p>In a related question, it was noted that __func__ is implicitly required to be unique in each function, and that not only the value but the type of __func__ are implementation-defined; e.g., in something like</p>
       <p>  inline auto f() { return &amp;__func__; }</p>
       <p>the function type is implementation-specific. These concerns could be addressed by making the value a prvalue of type const char* instead of an array lvalue.</p>
       <p>Rationale (November, 2018): See also issue <a href="http://wg21.link/cwg2362"><span>2362</span></a>, which asks for the ability to use __func__ in a constexpr function. These two goals are incompatible.</p>
       <p>The deep question here is about __func__ and the ODR. Does EWG want implementations to somehow behave as if __func__ is the same in all copies of an inline function (in which case it can have an array type and be usable in constant expressions, but the <em>demangling</em> algorithm used to construct it becomes part of the ABI), or does EWG want implementations to behave as if __func__ may differ between copies, so is in effect not known until runtime (in which case it must have either pointer or incomplete array type, and its value is not usable in constant expressions -- but its address could still be usable).</p>
       <p>Note: C++20 has std::source_location::function_name.</p>
       <p><br></p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020"><span>notes 2020-04-23</span></a>) We should discuss this with WG14. This is indeed a language issue. No objection to unanimous consent. We’ll need a paper, potentially considering what Reflection could do, JF <a href="https://lists.isocpp.org/ext/2020/04/13417.php"><span>brought it up on the mailing list</span></a>.</p>
       <p>We probably need a paper to disentangle this.</p>
      <td valign="top">
       <p>Paper needed</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg2228">[CWG2228]</a></p>
      <td valign="top">
       <p>Ambiguity resolution for cast to function type</p>
      <td valign="top">
       <p><span><a href="http://wiki.edg.com/pub/Wg21summer2020/CoreWorkingGroup/cwg2228.html?twiki_redirect_cache=5aceede89e9128019e50cb532244e26f">Proposed resolution.</a></span></p>
       <p><br></p>
       <p>C++ has a blanket disambiguation rule that says if a sequence of tokens can be interpreted as either a type-name or an expression, the type-name interpretation is chosen. This is unhelpful in cases like</p>
       <p><br></p>
       <p>    (T())+3</p>
       <p><br></p>
       <p>where the current rules make "(T())" a cast to the type "function with no parameters returning T" rather than a parenthesized value-initialization of a temporary of type T. The former interpretation is always ill-formed - you can’t cast to a function type - while the latter could be useful.</p>
       <p><br></p>
       <p>Richard’s proposed resolution, cited above, is to avoid the ambiguity by changing the grammar so that cases like "(T())" cannot be parsed as a cast. The wording in the proposal applies that change to a number of different contexts where the ambiguity can come into play. There are two contexts where the change is _not_ applied, however: 1) the operand of typeid, and 2) a template-argument. During our discussion yesterday, there was some support for the idea of applying the change to typeid, as well, although that would be a breaking change for any programs that rely on the current disambiguation to get type information for such function types. There was general agreement, however, to exclude template arguments, since they are used for things like std::function.</p>
       <p><br></p>
       <p>CWG would, therefore, like some guidance from EWG on two questions. First, should we apply the new syntax to the operand of typeid, even though it’s a breaking change?</p>
       <p><br></p>
       <p>More generally, the question was raised whether we should make this change at all. Although resolving the ambiguity in the other direction would arguably be more convenient in many cases, there is a tension between that convenience and the complexity of the language. In particular, we would be creating a situation where the exact same sequence of tokens would mean two different things, depending on the context in which they appear. Is the convenience worth the cost in complexity?</p>
       <p><br></p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-29-Apr-2020"><span>note 2020-04-29</span></a>, <a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssuesProcessingTeleconference2020-03-23"><span>notes 2020-03-23</span></a>, <a href="https://wiki.edg.com/bin/view/Wg21summer2020/CoreWorkingGroup"><span>note from Core summer 2020</span></a>, <a href="https://wiki.edg.com/bin/view/Wg21prague/CoreWorkingGroup"><span>notes from Core Prague 2020</span></a>, <a href="https://wiki.edg.com/bin/view/Wg21kona2019/IssuesProcessingTeleconference,2019-01-07"><span>notes from Core 2019-01-07</span></a>, <a href="https://wiki.edg.com/bin/view/Wg21kona2019/CoreWorkingGroup"><span>notes from Core Kona 2019</span></a>, <a href="https://wiki.edg.com/bin/view/Wg21cologne2019/CoreWorkingGroup"><span>notes from Core Cologne 2019</span></a>) This is an issue, we’d like to change the standard to resolve it: SF 0 F 6 N 4 A 3 SA 2</p>
       <p>Davis <a href="http://lists.isocpp.org/ext/2020/04/13473.php"><span>emailed EWG reflector</span></a>. Long discussion.</p>
      <td valign="top">
       <p>Paper needed</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg2296">[CWG2296]</a></p>
      <td valign="top">
       <p>Are default argument instantiation failures in the “immediate context”?</p>
      <td valign="top">
       <p>Example 1:</p>
       <p>template &lt;typename T, typename U = T></p>
       <p>void fun(T v, U u = U()) {}</p>
       <p>void fun(...) {}</p>
       <p>struct X {</p>
       <p>    X(int) {} // no default ctor</p>
       <p>};</p>
       <p>int main()  {  fun (X(1)); }</p>
       <p><br></p>
       <p>Consider the following example (taken from issue 3 of paper <a href="http://wg21.link/P0348R0"><span>P0348R0</span></a>):</p>
       <p>Example 2:</p>
       <p>  template &lt;typename U> void fun(U u = U());</p>
       <p>  struct X {</p>
       <p>    X(int) {}</p>
       <p>  };</p>
       <p>  template &lt;class T> decltype(fun&lt;T>()) g(int) { }</p>
       <p>  template &lt;class> void g(long) { }</p>
       <p>  int main() { g&lt;X>(0); }</p>
       <p>When is the substitution into the return type done? The current specification makes this example ill-formed because the failure to instantiate the default argument in the decltype operand is not in the immediate context of the substitution, although a plausible argument for making this a SFINAE case can be made.</p>
       <p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-07-May-2020"><span>notes 2020-05-07</span></a>)</p>
       <p>The first example under issue 3 of paper P0348R0 should become well-formed.</p>
       <p>SF F N A SA</p>
       <p>0 1 4 3 6</p>
       <p>The second example under issue 3 of paper P0348R0 should become well-formed.</p>
       <p>SF F N A SA</p>
       <p>1 5 7 3 0</p>
       <p>This is an issue. We’d like to see a paper addressing it. It should explore what “Immediate context” means. No objection to unanimous consent.</p>
       <p>Daveed / Hubert might entertain writing a paper explaining this.</p>
       <p>Ville <a href="http://lists.isocpp.org/ext/2020/05/13733.php"><span>emailed EWG about this</span></a>.</p>
       <p>JF contacted Andrzej to see if he’s interested in addressing this. Not sure he is.</p>
       <p><br></p>
       <p><b>Meeting 2020-10-28</b>: Tomasz will write a paper which exposes the issue and what he thinks should be done (but not resolving wording itself). Hubert remembers an email about this, will find it and sync with JF.</p>
       <p><br></p>
       <p><b>Meeting 2021-01-14:</b> Andrzej wrote a paper for this (<a href="https://lists.isocpp.org/ext/2021/01/15505.php"><span>emailed 2021-01-12 to EWG</span></a>).</p>
      <td valign="top">
       <p>Paper needed</p>
     <tr>
      <td valign="top">
       <p>Core</p>
      <td valign="top">
       <p><a data-link-type="biblio" href="#biblio-cwg2362">[CWG2362]</a></p>
      <td valign="top">
       <p>__func__ should be constexpr</p>
      <td valign="top">
       <p>The definition of __func__ in 9.5.1 [dcl.fct.def.general] paragraph 8 is:</p>
       <p>  static const char __func__[] = "function-name";</p>
       <p>This prohibits its use in constant expressions, e.g.,</p>
       <p>  int main () {</p>
       <p>    // error: the value of __func__ is not usable in a constant expression</p>
       <p>    constexpr char c = __func__[0];</p>
       <p>  }</p>
       <p>Rationale (November, 2018): See also issue <a href="http://wg21.link/cwg1962"><span>1962</span></a>, which asks that the type of __func__ be const char*. These two goals are incompatible.</p>
       <p><br></p>
       <p><b>Meeting:</b> handle with 1962.</p>
      <td valign="top">
       <p>Paper needed</p>
   </table>
   <h2 class="heading settled" data-level="8" id="future"><span class="secno">8. </span><span class="content">Near-future EWG plans</span><a class="self-link" href="#future"></a></h2>
   <p>We will continue to work on issue resolution and C++23, prioritizing according to <a data-link-type="biblio" href="#biblio-p0592r4">[P0592R4]</a>.</p>
  </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-cwg1008">[CWG1008]
   <dd>Steve Clamage. <a href="https://wg21.link/cwg1008">Querying the alignment of an object</a>. 27 November 2009. extension. URL: <a href="https://wg21.link/cwg1008">https://wg21.link/cwg1008</a>
   <dt id="biblio-cwg1077">[CWG1077]
   <dd>Mike Spertus. <a href="https://wg21.link/cwg1077">Explicit specializations in non-containing namespaces</a>. 13 June 2010. extension. URL: <a href="https://wg21.link/cwg1077">https://wg21.link/cwg1077</a>
   <dt id="biblio-cwg1326">[CWG1326]
   <dd>Faisal Vali. <a href="https://wg21.link/cwg1326">Deducing an array bound from an initializer-list</a>. 28 May 2011. extension. URL: <a href="https://wg21.link/cwg1326">https://wg21.link/cwg1326</a>
   <dt id="biblio-cwg1331">[CWG1331]
   <dd>Daniel Krügler. <a href="https://wg21.link/cwg1331">const mismatch with defaulted copy constructor</a>. 15 June 2011. extension. URL: <a href="https://wg21.link/cwg1331">https://wg21.link/cwg1331</a>
   <dt id="biblio-cwg1393">[CWG1393]
   <dd>Daniel Krügler. <a href="https://wg21.link/cwg1393">Pack expansions in using-declarations</a>. 10 September 2011. extension. URL: <a href="https://wg21.link/cwg1393">https://wg21.link/cwg1393</a>
   <dt id="biblio-cwg1426">[CWG1426]
   <dd>Nikolay Ivchenkov. <a href="https://wg21.link/cwg1426">Allowing additional parameter types in defaulted functions</a>. 8 December 2011. extension. URL: <a href="https://wg21.link/cwg1426">https://wg21.link/cwg1426</a>
   <dt id="biblio-cwg1433">[CWG1433]
   <dd>Jason Merrill. <a href="https://wg21.link/cwg1433">trailing-return-type and point of declaration</a>. 20 December 2011. extension. URL: <a href="https://wg21.link/cwg1433">https://wg21.link/cwg1433</a>
   <dt id="biblio-cwg1451">[CWG1451]
   <dd>Daniel Krügler. <a href="https://wg21.link/cwg1451">Objects with no linkage in non-type template arguments</a>. 1 February 2012. extension. URL: <a href="https://wg21.link/cwg1451">https://wg21.link/cwg1451</a>
   <dt id="biblio-cwg1463">[CWG1463]
   <dd>Daveed Vandevoorde. <a href="https://wg21.link/cwg1463">extern "C" alias templates</a>. 19 August 2011. extension. URL: <a href="https://wg21.link/cwg1463">https://wg21.link/cwg1463</a>
   <dt id="biblio-cwg1469">[CWG1469]
   <dd>Johannes Schaub. <a href="https://wg21.link/cwg1469">Omitted bound in array new-expression</a>. 12 February 2012. extension. URL: <a href="https://wg21.link/cwg1469">https://wg21.link/cwg1469</a>
   <dt id="biblio-cwg1555">[CWG1555]
   <dd>Daniel Krügler. <a href="https://wg21.link/cwg1555">Language linkage and function type compatibility</a>. 18 September 2012. extension. URL: <a href="https://wg21.link/cwg1555">https://wg21.link/cwg1555</a>
   <dt id="biblio-cwg1561">[CWG1561]
   <dd>Gabriel Dos Reis. <a href="https://wg21.link/cwg1561">Aggregates with empty base classes</a>. 29 September 2012. extension. URL: <a href="https://wg21.link/cwg1561">https://wg21.link/cwg1561</a>
   <dt id="biblio-cwg1591">[CWG1591]
   <dd>Peter Dimov. <a href="https://wg21.link/cwg1591">Deducing array bound and element type from initializer list</a>. 1 December 2012. CD4. URL: <a href="https://wg21.link/cwg1591">https://wg21.link/cwg1591</a>
   <dt id="biblio-cwg1643">[CWG1643]
   <dd>Vinny Romano. <a href="https://wg21.link/cwg1643">Default arguments for template parameter packs</a>. 17 March 2013. extension. URL: <a href="https://wg21.link/cwg1643">https://wg21.link/cwg1643</a>
   <dt id="biblio-cwg1698">[CWG1698]
   <dd>David Krauss. <a href="https://wg21.link/cwg1698">Files ending in \</a>. 10 June 2013. open. URL: <a href="https://wg21.link/cwg1698">https://wg21.link/cwg1698</a>
   <dt id="biblio-cwg1790">[CWG1790]
   <dd>Daryle Walker. <a href="https://wg21.link/cwg1790">Ellipsis following function parameter pack</a>. 1 October 2013. extension. URL: <a href="https://wg21.link/cwg1790">https://wg21.link/cwg1790</a>
   <dt id="biblio-cwg1864">[CWG1864]
   <dd>Alisdair Meredith. <a href="https://wg21.link/cwg1864">List-initialization of array objects</a>. 15 February 2014. extension. URL: <a href="https://wg21.link/cwg1864">https://wg21.link/cwg1864</a>
   <dt id="biblio-cwg1871">[CWG1871]
   <dd>Richard Smith. <a href="https://wg21.link/cwg1871">Non-identifier characters in ud-suffix</a>. 17 February 2014. extension. URL: <a href="https://wg21.link/cwg1871">https://wg21.link/cwg1871</a>
   <dt id="biblio-cwg1876">[CWG1876]
   <dd>John Spicer. <a href="https://wg21.link/cwg1876">Preventing explicit specialization</a>. 19 February 2014. extension. URL: <a href="https://wg21.link/cwg1876">https://wg21.link/cwg1876</a>
   <dt id="biblio-cwg1912">[CWG1912]
   <dd>Ville Voutilainen. <a href="https://wg21.link/cwg1912">exception-specification of defaulted function</a>. 10 April 2014. extension. URL: <a href="https://wg21.link/cwg1912">https://wg21.link/cwg1912</a>
   <dt id="biblio-cwg1914">[CWG1914]
   <dd>Aaron Ballman. <a href="https://wg21.link/cwg1914">Duplicate standard attributes</a>. 15 April 2014. extension. URL: <a href="https://wg21.link/cwg1914">https://wg21.link/cwg1914</a>
   <dt id="biblio-cwg1915">[CWG1915]
   <dd>Aaron Ballman. <a href="https://wg21.link/cwg1915">Potentially-invoked destructors in non-throwing constructors</a>. 15 April 2014. extension. URL: <a href="https://wg21.link/cwg1915">https://wg21.link/cwg1915</a>
   <dt id="biblio-cwg1923">[CWG1923]
   <dd>Richard Smith. <a href="https://wg21.link/cwg1923">Lvalues of type void</a>. 6 May 2014. extension. URL: <a href="https://wg21.link/cwg1923">https://wg21.link/cwg1923</a>
   <dt id="biblio-cwg1931">[CWG1931]
   <dd>Ryou Ezoe. <a href="https://wg21.link/cwg1931">Default-constructible and copy-assignable closure types</a>. 24 May 2014. extension. URL: <a href="https://wg21.link/cwg1931">https://wg21.link/cwg1931</a>
   <dt id="biblio-cwg1934">[CWG1934]
   <dd>Vinny Romano. <a href="https://wg21.link/cwg1934">Relaxing exception-specification compatibility requirements</a>. 3 June 2014. extension. URL: <a href="https://wg21.link/cwg1934">https://wg21.link/cwg1934</a>
   <dt id="biblio-cwg1957">[CWG1957]
   <dd>Vinny Romano. <a href="https://wg21.link/cwg1957">decltype(auto) with direct-list-initialization</a>. 20140630. extension. URL: <a href="https://wg21.link/cwg1957">https://wg21.link/cwg1957</a>
   <dt id="biblio-cwg1962">[CWG1962]
   <dd>Steve Clamage. <a href="https://wg21.link/cwg1962">Type of __func__</a>. 4 July 2014. drafting. URL: <a href="https://wg21.link/cwg1962">https://wg21.link/cwg1962</a>
   <dt id="biblio-cwg2039">[CWG2039]
   <dd>Richard Smith. <a href="https://wg21.link/cwg2039">Constant conversions to bool</a>. 9 November 2014. CD4. URL: <a href="https://wg21.link/cwg2039">https://wg21.link/cwg2039</a>
   <dt id="biblio-cwg2097">[CWG2097]
   <dd>Jonathan Caves. <a href="https://wg21.link/cwg2097">Lambdas and noreturn attribute</a>. 12 March 2015. extension. URL: <a href="https://wg21.link/cwg2097">https://wg21.link/cwg2097</a>
   <dt id="biblio-cwg2111">[CWG2111]
   <dd>Vinny Romano. <a href="https://wg21.link/cwg2111">Array temporaries in reference binding</a>. 2 April 2015. extension. URL: <a href="https://wg21.link/cwg2111">https://wg21.link/cwg2111</a>
   <dt id="biblio-cwg2125">[CWG2125]
   <dd>Vinny Romano. <a href="https://wg21.link/cwg2125">Copy elision and comma operator</a>. 6 May 2015. extension. URL: <a href="https://wg21.link/cwg2125">https://wg21.link/cwg2125</a>
   <dt id="biblio-cwg2132">[CWG2132]
   <dd>Nico Josuttis. <a href="https://wg21.link/cwg2132">Deprecated default generated copy constructors</a>. 28 May 2015. extension. URL: <a href="https://wg21.link/cwg2132">https://wg21.link/cwg2132</a>
   <dt id="biblio-cwg2169">[CWG2169]
   <dd>David Krauss. <a href="https://wg21.link/cwg2169">Narrowing conversions and overload resolution</a>. 26 August 2015. extension. URL: <a href="https://wg21.link/cwg2169">https://wg21.link/cwg2169</a>
   <dt id="biblio-cwg2228">[CWG2228]
   <dd>Richard Smith. <a href="https://wg21.link/cwg2228">Ambiguity resolution for cast to function type</a>. 2 February 2016. drafting. URL: <a href="https://wg21.link/cwg2228">https://wg21.link/cwg2228</a>
   <dt id="biblio-cwg2261">[CWG2261]
   <dd>Jens Maurer. <a href="https://wg21.link/cwg2261">Explicit instantiation of in-class friend definition</a>. 28 April 2016. extension. URL: <a href="https://wg21.link/cwg2261">https://wg21.link/cwg2261</a>
   <dt id="biblio-cwg2270">[CWG2270]
   <dd>Richard Smith. <a href="https://wg21.link/cwg2270">Non-inline functions and explicit instantiation declarations</a>. 10 June 2016. extension. URL: <a href="https://wg21.link/cwg2270">https://wg21.link/cwg2270</a>
   <dt id="biblio-cwg2295">[CWG2295]
   <dd>Thomas Köppe. <a href="https://wg21.link/cwg2295">Aggregates with deleted defaulted constructors</a>. 24 June 2016. extension. URL: <a href="https://wg21.link/cwg2295">https://wg21.link/cwg2295</a>
   <dt id="biblio-cwg2296">[CWG2296]
   <dd>Jason Merrill. <a href="https://wg21.link/cwg2296">Are default argument instantiation failures in the “immediate context”?</a>. 25 June 2016. extension. URL: <a href="https://wg21.link/cwg2296">https://wg21.link/cwg2296</a>
   <dt id="biblio-cwg2320">[CWG2320]
   <dd>Richard Smith. <a href="https://wg21.link/cwg2320">constexpr if and boolean conversions</a>. 6 September 2016. extension. URL: <a href="https://wg21.link/cwg2320">https://wg21.link/cwg2320</a>
   <dt id="biblio-cwg2341">[CWG2341]
   <dd>John Spicer. <a href="https://wg21.link/cwg2341">Structured bindings with static storage duration</a>. 4 April 2017. extension. URL: <a href="https://wg21.link/cwg2341">https://wg21.link/cwg2341</a>
   <dt id="biblio-cwg2343">[CWG2343]
   <dd>Daveed Vandevoorde. <a href="https://wg21.link/cwg2343">void* non-type template parameters</a>. 17 April 2017. extension. URL: <a href="https://wg21.link/cwg2343">https://wg21.link/cwg2343</a>
   <dt id="biblio-cwg2355">[CWG2355]
   <dd>John Spicer. <a href="https://wg21.link/cwg2355">Deducing noexcept-specifiers</a>. 6 September 2017. extension. URL: <a href="https://wg21.link/cwg2355">https://wg21.link/cwg2355</a>
   <dt id="biblio-cwg2362">[CWG2362]
   <dd>Anthony Polukhin. <a href="https://wg21.link/cwg2362">__func__ should be constexpr</a>. 23 October 2017. open. URL: <a href="https://wg21.link/cwg2362">https://wg21.link/cwg2362</a>
   <dt id="biblio-cwg2382">[CWG2382]
   <dd>Paul Sanders. <a href="https://wg21.link/cwg2382">Array allocation overhead for non-allocating placement new</a>. 16 July 2018. review. URL: <a href="https://wg21.link/cwg2382">https://wg21.link/cwg2382</a>
   <dt id="biblio-cwg476">[CWG476]
   <dd>Ben Hutchings. <a href="https://wg21.link/cwg476">Determining the buffer size for placement new</a>. 14 September 2004. extension. URL: <a href="https://wg21.link/cwg476">https://wg21.link/cwg476</a>
   <dt id="biblio-cwg687">[CWG687]
   <dd>Mihai Rusu. <a href="https://wg21.link/cwg687">template keyword with unqualified-ids</a>. 27 February 2008. extension. URL: <a href="https://wg21.link/cwg687">https://wg21.link/cwg687</a>
   <dt id="biblio-cwg728">[CWG728]
   <dd>Faisal Vali. <a href="https://wg21.link/cwg728">Restrictions on local classes</a>. 5 October 2008. extension. URL: <a href="https://wg21.link/cwg728">https://wg21.link/cwg728</a>
   <dt id="biblio-cwg794">[CWG794]
   <dd>CH. <a href="https://wg21.link/cwg794">Base-derived conversion in member type of pointer-to-member conversion</a>. 3 March 2009. extension. URL: <a href="https://wg21.link/cwg794">https://wg21.link/cwg794</a>
   <dt id="biblio-cwg900">[CWG900]
   <dd>Thomas J. Gritzan. <a href="https://wg21.link/cwg900">Lifetime of temporaries in range-based for</a>. 12 May 2009. extension. URL: <a href="https://wg21.link/cwg900">https://wg21.link/cwg900</a>
   <dt id="biblio-cwg914">[CWG914]
   <dd>Gabriel Dos Reis. <a href="https://wg21.link/cwg914">Value-initialization of array types</a>. 10 June 2009. extension. URL: <a href="https://wg21.link/cwg914">https://wg21.link/cwg914</a>
   <dt id="biblio-cwg944">[CWG944]
   <dd>Miller. <a href="https://wg21.link/cwg944">reinterpret_cast for all types with the same size and alignment</a>. 15 July 2009. extension. URL: <a href="https://wg21.link/cwg944">https://wg21.link/cwg944</a>
   <dt id="biblio-lwg2432">[LWG2432]
   <dd>David Krauss. <a href="https://wg21.link/lwg2432">initializer_list assignability</a>. EWG. URL: <a href="https://wg21.link/lwg2432">https://wg21.link/lwg2432</a>
   <dt id="biblio-lwg2813">[LWG2813]
   <dd>Brian Bi. <a href="https://wg21.link/lwg2813">std::function should not return dangling references</a>. EWG. URL: <a href="https://wg21.link/lwg2813">https://wg21.link/lwg2813</a>
   <dt id="biblio-n2557">[N2557]
   <dd>Melanie Blower. <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2557.pdf">Allow Duplicate Attributes</a>. 01 September 2020. URL: <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2557.pdf">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2557.pdf</a>
   <dt id="biblio-n2594">[N2594]
   <dd>JeanHeyd Meneide. <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2594.htm">Mixed Wide String Literal Concatenation</a>. 26 October 2020. URL: <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2594.htm">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2594.htm</a>
   <dt id="biblio-p0017r1">[P0017r1]
   <dd>Oleg Smolsky. <a href="https://wg21.link/p0017r1">Extension to aggregate initialization</a>. 24 October 2015. URL: <a href="https://wg21.link/p0017r1">https://wg21.link/p0017r1</a>
   <dt id="biblio-p0127r2">[P0127R2]
   <dd>James Touton, Mike Spertus. <a href="https://wg21.link/p0127r2">Declaring non-type template arguments with auto</a>. 23 June 2016. URL: <a href="https://wg21.link/p0127r2">https://wg21.link/p0127r2</a>
   <dt id="biblio-p0195r2">[P0195r2]
   <dd>Robert Haberlach, Richard Smith. <a href="https://wg21.link/p0195r2">Pack expansions in using-declarations</a>. 8 November 2016. URL: <a href="https://wg21.link/p0195r2">https://wg21.link/p0195r2</a>
   <dt id="biblio-p0443r14">[P0443R14]
   <dd>Jared Hoberock, Michael Garland, Chris Kohlhoff, Chris Mysen, H. Carter Edwards, Gordon Brown, D. S. Hollman. <a href="https://wg21.link/p0443r14">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-p0515r3">[P0515R3]
   <dd>Herb Sutter, Jens Maurer, Walter E. Brown. <a href="https://wg21.link/p0515r3">Consistent comparison</a>. 10 November 2017. URL: <a href="https://wg21.link/p0515r3">https://wg21.link/p0515r3</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-p0624r2">[P0624r2]
   <dd>Louis Dionne. <a href="https://wg21.link/p0624r2">Default constructible and assignable stateless lambdas</a>. 10 November 2017. URL: <a href="https://wg21.link/p0624r2">https://wg21.link/p0624r2</a>
   <dt id="biblio-p0641r2">[P0641r2]
   <dd>Daniel Krügler, Botond Ballo. <a href="https://wg21.link/p0641r2">Resolving Core Issue #1331 (const mismatch with defaulted copy constructor)</a>. 8 November 2017. URL: <a href="https://wg21.link/p0641r2">https://wg21.link/p0641r2</a>
   <dt id="biblio-p0732r2">[P0732R2]
   <dd>Jeff Snyder, Louis Dionne. <a href="https://wg21.link/p0732r2">Class Types in Non-Type Template Parameters</a>. 6 June 2018. URL: <a href="https://wg21.link/p0732r2">https://wg21.link/p0732r2</a>
   <dt id="biblio-p0846r0">[P0846r0]
   <dd>John Spicer. <a href="https://wg21.link/p0846r0">ADL and Function Templates that are not Visible</a>. 8 November 2017. URL: <a href="https://wg21.link/p0846r0">https://wg21.link/p0846r0</a>
   <dt id="biblio-p1000r4">[P1000R4]
   <dd>Herb Sutter. <a href="https://wg21.link/p1000r4">C++ IS schedule</a>. 14 February 2020. URL: <a href="https://wg21.link/p1000r4">https://wg21.link/p1000r4</a>
   <dt id="biblio-p1008r1">[P1008r1]
   <dd>Timur Doumler, Arthur O’Dwyer, Richard Smith, Howard E. Hinnant, Nicolai Josuttis. <a href="https://wg21.link/p1008r1">Prohibit aggregates with user-declared constructors</a>. 8 June 2018. URL: <a href="https://wg21.link/p1008r1">https://wg21.link/p1008r1</a>
   <dt id="biblio-p1091r3">[P1091r3]
   <dd>Nicolas Lesser. <a href="https://wg21.link/p1091r3">Extending structured bindings to be more like variable declarations</a>. 18 February 2019. URL: <a href="https://wg21.link/p1091r3">https://wg21.link/p1091r3</a>
   <dt id="biblio-p1286r2">[P1286R2]
   <dd>Richard Smith. <a href="https://wg21.link/p1286r2">Contra CWG DR1778</a>. 18 February 2019. URL: <a href="https://wg21.link/p1286r2">https://wg21.link/p1286r2</a>
   <dt id="biblio-p1371r3">[P1371R3]
   <dd>Michael Park, Bruno Cardoso Lopes, Sergei Murzin, David Sankel, Dan Sarginson, Bjarne Stroustrup. <a href="https://wg21.link/p1371r3">Pattern Matching</a>. 15 September 2020. URL: <a href="https://wg21.link/p1371r3">https://wg21.link/p1371r3</a>
   <dt id="biblio-p1393r0">[P1393R0]
   <dd>D. S. Hollman, Chris Kohlhoff, Bryce Lelbach, Jared Hoberock, Gordon Brown, Michał Dominiak. <a href="https://wg21.link/p1393r0">A General Property Customization Mechanism</a>. 13 January 2019. URL: <a href="https://wg21.link/p1393r0">https://wg21.link/p1393r0</a>
   <dt id="biblio-p1401r3">[P1401R3]
   <dd>Andrzej Krzemieński. <a href="https://wg21.link/p1401r3">Narrowing contextual conversions to bool</a>. 27 May 2020. URL: <a href="https://wg21.link/p1401r3">https://wg21.link/p1401r3</a>
   <dt id="biblio-p1401r4">[P1401R4]
   <dd>Andrzej Krzemieński. <a href="https://wg21.link/p1401r4">Narrowing contextual conversions to bool</a>. 8 October 2020. URL: <a href="https://wg21.link/p1401r4">https://wg21.link/p1401r4</a>
   <dt id="biblio-p1467r4">[P1467R4]
   <dd>David Olsen, Michał Dominiak. <a href="https://wg21.link/p1467r4">Extended floating-point types and standard names</a>. 14 June 2020. URL: <a href="https://wg21.link/p1467r4">https://wg21.link/p1467r4</a>
   <dt id="biblio-p1701r1">[P1701R1]
   <dd>Nathan Sidwell. <a href="https://wg21.link/p1701r1">Inline Namespaces: Fragility Bites</a>. 13 September 2020. URL: <a href="https://wg21.link/p1701r1">https://wg21.link/p1701r1</a>
   <dt id="biblio-p1726r3">[P1726R3]
   <dd>Paul E. McKenney, Maged Michael, Jens Mauer, Peter Sewell, Martin Uecker, Hans Boehm, Hubert Tong, Niall Douglas, Will Deacon, Michael Wong, and David Goldblatt. <a href="https://wg21.link/p1726r3">Pointer lifetime-end zap</a>. 21 February 2020. URL: <a href="https://wg21.link/p1726r3">https://wg21.link/p1726r3</a>
   <dt id="biblio-p1787r6">[P1787R6]
   <dd>S. Davis Herring. <a href="https://wg21.link/p1787r6">Declarations and where to find them</a>. 28 October 2020. URL: <a href="https://wg21.link/p1787r6">https://wg21.link/p1787r6</a>
   <dt id="biblio-p1847r3">[P1847R3]
   <dd>Pal Balog. <a href="https://wg21.link/p1847r3">Make declaration order layout mandated</a>. 1 March 2020. URL: <a href="https://wg21.link/p1847r3">https://wg21.link/p1847r3</a>
   <dt id="biblio-p1858r2">[P1858R2]
   <dd>Barry Revzin. <a href="https://wg21.link/p1858r2">Generalized pack declaration and usage</a>. 1 March 2020. URL: <a href="https://wg21.link/p1858r2">https://wg21.link/p1858r2</a>
   <dt id="biblio-p1875r0">[P1875R0]
   <dd>Michael Spear, Hans Boehm, Victor Luchangco, Michael Scott, Michael Wong. <a href="https://wg21.link/p1875r0">Transactional Memory Lite Support in C++</a>. 7 October 2019. URL: <a href="https://wg21.link/p1875r0">https://wg21.link/p1875r0</a>
   <dt id="biblio-p1907r1">[P1907R1]
   <dd>Jens Maurer. <a href="https://wg21.link/p1907r1">Inconsistencies with non-type template parameters</a>. 8 November 2019. URL: <a href="https://wg21.link/p1907r1">https://wg21.link/p1907r1</a>
   <dt id="biblio-p1938r1">[P1938R1]
   <dd>Barry Revzin, Daveed Vandevoorde, Richard Smith, Andrew Sutton. <a href="https://wg21.link/p1938r1">if consteval</a>. 2 March 2020. URL: <a href="https://wg21.link/p1938r1">https://wg21.link/p1938r1</a>
   <dt id="biblio-p1938r2">[P1938R2]
   <dd>Barry Revzin, Daveed Vandevoorde, Richard Smith, Andrew Sutton. <a href="https://wg21.link/p1938r2">if consteval</a>. 14 October 2020. URL: <a href="https://wg21.link/p1938r2">https://wg21.link/p1938r2</a>
   <dt id="biblio-p1949r4">[P1949R4]
   <dd>Steve Downey, Zach Laine, Tom Honermann, Peter Bindels, Jens Maurer. <a href="https://wg21.link/p1949r4">C++ Identifier Syntax using Unicode Standard Annex 31</a>. 5 June 2020. URL: <a href="https://wg21.link/p1949r4">https://wg21.link/p1949r4</a>
   <dt id="biblio-p1949r6">[P1949R6]
   <dd>Steve Downey, Zach Laine, Tom Honermann, Peter Bindels, Jens Maurer. <a href="https://wg21.link/p1949r6">C++ Identifier Syntax using Unicode Standard Annex 31</a>. 15 September 2020. URL: <a href="https://wg21.link/p1949r6">https://wg21.link/p1949r6</a>
   <dt id="biblio-p1967r2">[P1967R2]
   <dd>JeanHeyd Meneide. <a href="https://wg21.link/p1967r2">#embed - a simple, scannable preprocessor-based resource acquisition method</a>. 2 March 2020. URL: <a href="https://wg21.link/p1967r2">https://wg21.link/p1967r2</a>
   <dt id="biblio-p1969r0">[P1969r0]
   <dd>William M. (Mike) Miller. <a href="https://wg21.link/p1969r0">Core Language Working Group "ready" issues for the November, 2019 (Belfast) meeting</a>. 8 November 2019. URL: <a href="https://wg21.link/p1969r0">https://wg21.link/p1969r0</a>
   <dt id="biblio-p1999r0">[P1999R0]
   <dd>Ville Voutilainen. <a href="https://wg21.link/p1999r0">Process proposal: double-check evolutionary material via a Tentatively Ready status</a>. 25 November 2019. URL: <a href="https://wg21.link/p1999r0">https://wg21.link/p1999r0</a>
   <dt id="biblio-p2011r1">[P2011R1]
   <dd>Barry Revzin, Colby Pike. <a href="https://wg21.link/p2011r1">A pipeline-rewrite operator</a>. 16 April 2020. URL: <a href="https://wg21.link/p2011r1">https://wg21.link/p2011r1</a>
   <dt id="biblio-p2013r2">[P2013R2]
   <dd>Ben Craig. <a href="https://wg21.link/p2013r2">Freestanding Language: Optional ::operator new</a>. 14 August 2020. URL: <a href="https://wg21.link/p2013r2">https://wg21.link/p2013r2</a>
   <dt id="biblio-p2013r3">[P2013R3]
   <dd>Ben Craig. <a href="https://wg21.link/p2013r3">Freestanding Language: Optional ::operator new</a>. 13 September 2020. URL: <a href="https://wg21.link/p2013r3">https://wg21.link/p2013r3</a>
   <dt id="biblio-p2025r1">[P2025R1]
   <dd>Anton Zhilin. <a href="https://wg21.link/p2025r1">Guaranteed copy elision for return variables</a>. 15 June 2020. URL: <a href="https://wg21.link/p2025r1">https://wg21.link/p2025r1</a>
   <dt id="biblio-p2044r0">[P2044R0]
   <dd>Robert Leahy. <a href="https://wg21.link/p2044r0">Member Templates for Local Classes</a>. 12 January 2020. URL: <a href="https://wg21.link/p2044r0">https://wg21.link/p2044r0</a>
   <dt id="biblio-p2139r1">[P2139R1]
   <dd>Alisdair Meredith. <a href="https://wg21.link/p2139r1">Reviewing Deprecated Facilities of C++20 for C++23</a>. 15 June 2020. URL: <a href="https://wg21.link/p2139r1">https://wg21.link/p2139r1</a>
   <dt id="biblio-p2139r2">[P2139R2]
   <dd>Alisdair Meredith. <a href="https://wg21.link/p2139r2">Reviewing Deprecated Facilities of C++20 for C++23</a>. 15 July 2020. URL: <a href="https://wg21.link/p2139r2">https://wg21.link/p2139r2</a>
   <dt id="biblio-p2145r1">[P2145R1]
   <dd>Bryce Adelstein Lelbach, Titus Winters, Fabio Fracassi, Billy Baker, Nevin Liber, JF Bastien, David Stone, Botond Ballo, Tom Honermann. <a href="https://wg21.link/p2145r1">Evolving C++ Remotely</a>. 15 September 2020. URL: <a href="https://wg21.link/p2145r1">https://wg21.link/p2145r1</a>
   <dt id="biblio-p2156r0">[P2156R0]
   <dd>Erich Keane. <a href="https://wg21.link/p2156r0">Allow Duplicate Attributes</a>. 15 April 2020. URL: <a href="https://wg21.link/p2156r0">https://wg21.link/p2156r0</a>
   <dt id="biblio-p2156r1">[P2156R1]
   <dd>Erich Keane. <a href="https://wg21.link/p2156r1">Allow Duplicate Attributes</a>. 2 July 2020. URL: <a href="https://wg21.link/p2156r1">https://wg21.link/p2156r1</a>
   <dt id="biblio-p2173r0">[P2173R0]
   <dd>Daveed Vandevoorde, Inbal Levi, Ville Voutilainen. <a href="https://wg21.link/p2173r0">Attributes on Lambda-Expressions</a>. 15 May 2020. URL: <a href="https://wg21.link/p2173r0">https://wg21.link/p2173r0</a>
   <dt id="biblio-p2174r0">[P2174R0]
   <dd>Zhihao Yuan. <a href="https://wg21.link/p2174r0">Compound Literals</a>. 16 May 2020. URL: <a href="https://wg21.link/p2174r0">https://wg21.link/p2174r0</a>
   <dt id="biblio-p2186r0">[P2186R0]
   <dd>JF Bastien, Alisdair Meredith. <a href="https://wg21.link/p2186r0">Removing Garbage Collection Support</a>. 12 July 2020. URL: <a href="https://wg21.link/p2186r0">https://wg21.link/p2186r0</a>
   <dt id="biblio-p2186r1">[P2186R1]
   <dd>JF Bastien; Alisdair Meredith. <a href="https://wg21.link/p2186r1">Removing Garbage Collection Support</a>. 14 December 2020. URL: <a href="https://wg21.link/p2186r1">https://wg21.link/p2186r1</a>
   <dt id="biblio-p2195r0">[P2195R0]
   <dd>Bryce Adelstein Lelbach. <a href="https://wg21.link/p2195r0">Electronic Straw Polls</a>. 15 September 2020. URL: <a href="https://wg21.link/p2195r0">https://wg21.link/p2195r0</a>
   <dt id="biblio-p2201r0">[P2201R0]
   <dd>Jens Maurer. <a href="https://wg21.link/p2201r0">Mixed string literal concatenation</a>. 14 July 2020. URL: <a href="https://wg21.link/p2201r0">https://wg21.link/p2201r0</a>
   <dt id="biblio-p2223r0">[P2223R0]
   <dd>Corentin Jabot. <a href="https://wg21.link/p2223r0">Trimming whitespaces before line splicing</a>. 14 September 2020. URL: <a href="https://wg21.link/p2223r0">https://wg21.link/p2223r0</a>
   <dt id="biblio-p2223r1">[P2223R1]
   <dd>Corentin Jabot. <a href="https://wg21.link/p2223r1">Trimming whitespaces before line splicing</a>. 17 October 2020. URL: <a href="https://wg21.link/p2223r1">https://wg21.link/p2223r1</a>
   <dt id="biblio-uax31">[UAX31]
   <dd>Mark Davis. <a href="https://www.unicode.org/reports/tr31/tr31-33.html">Unicode Identifier and Pattern Syntax</a>. 13 February 2020. Unicode Standard Annex #31. URL: <a href="https://www.unicode.org/reports/tr31/tr31-33.html">https://www.unicode.org/reports/tr31/tr31-33.html</a>
  </dl>