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

/* color variables included separately for reliability */

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

	html {
	}

	body {
		counter-reset: example figure issue;

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	p {
		margin: 1em 0;
	}

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

	/* Do something nice. */

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

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

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

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

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

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

	img {
		border-style: none;
	}

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


/*
Alternate table alignment rules

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

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

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

Possible extra rowspan handling

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

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

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


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

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

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

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

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

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

		.toc li {
			clear: both;
		}

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.outdated-warning span {
	display: block;
}

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

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

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

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

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



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

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

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

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

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

    del { background: #fcc; color: #000; text-decoration: line-through; }
    ins { background: #cfc; color: #000; }
    blockquote .highlight:not(.idl) { background: initial; margin: initial; padding: 0.5em }
    blockquote ul { background: inherit; }
    blockquote code.highlight:not(.idl) { padding: initial; }
    blockquote c-[a] { color: inherit; } /* Keyword.Declaration */
    blockquote c-[b] { color: inherit; } /* Keyword.Type */
    blockquote c-[c] { color: inherit; } /* Comment */
    blockquote c-[d] { color: inherit; } /* Comment.Multiline */
    blockquote c-[e] { color: inherit; } /* Name.Attribute */
    blockquote c-[f] { color: inherit; } /* Name.Tag */
    blockquote c-[g] { color: inherit; } /* Name.Variable */
    blockquote c-[k] { color: inherit; } /* Keyword */
    blockquote c-[l] { color: inherit; } /* Literal */
    blockquote c-[m] { color: inherit; } /* Literal.Number */
    blockquote c-[n] { color: inherit; } /* Name */
    blockquote c-[o] { color: inherit; } /* Operator */
    blockquote c-[p] { color: inherit; } /* Punctuation */
    blockquote c-[s] { color: inherit; } /* Literal.String */
    blockquote c-[t] { color: inherit; } /* Literal.String.Single */
    blockquote c-[u] { color: inherit; } /* Literal.String.Double */
    blockquote c-[cp] { color: inherit; } /* Comment.Preproc */
    blockquote c-[c1] { color: inherit; } /* Comment.Single */
    blockquote c-[cs] { color: inherit; } /* Comment.Special */
    blockquote c-[kc] { color: inherit; } /* Keyword.Constant */
    blockquote c-[kn] { color: inherit; } /* Keyword.Namespace */
    blockquote c-[kp] { color: inherit; } /* Keyword.Pseudo */
    blockquote c-[kr] { color: inherit; } /* Keyword.Reserved */
    blockquote c-[ld] { color: inherit; } /* Literal.Date */
    blockquote c-[nc] { color: inherit; } /* Name.Class */
    blockquote c-[no] { color: inherit; } /* Name.Constant */
    blockquote c-[nd] { color: inherit; } /* Name.Decorator */
    blockquote c-[ni] { color: inherit; } /* Name.Entity */
    blockquote c-[ne] { color: inherit; } /* Name.Exception */
    blockquote c-[nf] { color: inherit; } /* Name.Function */
    blockquote c-[nl] { color: inherit; } /* Name.Label */
    blockquote c-[nn] { color: inherit; } /* Name.Namespace */
    blockquote c-[py] { color: inherit; } /* Name.Property */
    blockquote c-[ow] { color: inherit; } /* Operator.Word */
    blockquote c-[mb] { color: inherit; } /* Literal.Number.Bin */
    blockquote c-[mf] { color: inherit; } /* Literal.Number.Float */
    blockquote c-[mh] { color: inherit; } /* Literal.Number.Hex */
    blockquote c-[mi] { color: inherit; } /* Literal.Number.Integer */
    blockquote c-[mo] { color: inherit; } /* Literal.Number.Oct */
    blockquote c-[sb] { color: inherit; } /* Literal.String.Backtick */
    blockquote c-[sc] { color: inherit; } /* Literal.String.Char */
    blockquote c-[sd] { color: inherit; } /* Literal.String.Doc */
    blockquote c-[se] { color: inherit; } /* Literal.String.Escape */
    blockquote c-[sh] { color: inherit; } /* Literal.String.Heredoc */
    blockquote c-[si] { color: inherit; } /* Literal.String.Interpol */
    blockquote c-[sx] { color: inherit; } /* Literal.String.Other */
    blockquote c-[sr] { color: inherit; } /* Literal.String.Regex */
    blockquote c-[ss] { color: inherit; } /* Literal.String.Symbol */
    blockquote c-[vc] { color: inherit; } /* Name.Variable.Class */
    blockquote c-[vg] { color: inherit; } /* Name.Variable.Global */
    blockquote c-[vi] { color: inherit; } /* Name.Variable.Instance */
    blockquote c-[il] { color: inherit; } /* Literal.Number.Integer.Long */
  </style>
  <meta content="Bikeshed version 83b904c2e, updated Wed Nov 3 17:20:53 2021 -0700" name="generator">
  <link href="https://wg21.link/p1467r6" rel="canonical">
  <link href="https://isocpp.org/favicon.ico" rel="icon">
<style>
.ins, ins, ins *, span.ins, span.ins * {
  background-color: rgb(200, 250, 200);
  color: rgb(0, 136, 0);
  text-decoration: underline;
}
.del, del, del *, span.del, span.del * {
  background-color: rgb(250, 200, 200);
  color: rgb(255, 0, 0);
  text-decoration: line-through;
  text-decoration-color: rgb(255, 0, 0);
}
ul {
  list-style-type: "- ";
}
blockquote {
  counter-reset: paragraph;
}
div.numbered, div.newnumbered {
  margin-left: 2em;
  margin-top: 1em;
  margin-bottom: 1em;
}
div.numbered:before, div.newnumbered:before {
  position: absolute;
  margin-left: -2em;
  display-style: block;
}
div.numbered:before {
  content: counter(paragraph);
  counter-increment: paragraph;
}
div.newnumbered:before {
  content: "�";
}
div.numbered ul, div.newnumbered ul {
  counter-reset: list_item;
}
div.numbered li, div.newnumbered li {
  margin-left: 3em;
}
div.numbered li:before, div.newnumbered li:before {
  position: absolute;
  margin-left: -4.8em;
  display-style: block;
}
div.numbered li:before {
  content: "(" counter(paragraph) "." counter(list_item) ")";
  counter-increment: list_item;
}
div.newnumbered li:before {
  content: "(�." counter(list_item) ")";
  counter-increment: list_item;
}
</style>
<style>/* style-autolinks */

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

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

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

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

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

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

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

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

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

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

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

    --heading-text: #005a9c;

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

    --algo-border: #def;

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

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

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

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

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

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

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

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

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

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

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

    --datacell-border: silver;

    --indexinfo-text: #707070;

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

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

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

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

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

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

            #hidedel:checked ~ del, #hidedel:checked ~ * del { display:none; }
            #hidedel ~ #hidedel-label::before, #hidedel ~ * #hidedel-label::before { content: "☐ "; }
            #hidedel:checked ~ #hidedel-label::before, #hidedel:checked ~ * #hidedel-label::before { content: "☑ "; }
        </style>
<style>/* style-issues */

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

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

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

a.self-link::before            { content: "¶"; }
.heading > a.self-link::before { content: "§"; }
dfn > a.self-link::before      { content: "#"; }
</style>
<style>/* style-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: rgba(0, 0, 0, .03); }
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;

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

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

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

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

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

        --heading-text: #8af;

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

        --algo-border: #456;

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

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

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

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

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

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

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

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

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

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

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

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

        --datacell-border: silver;

        --indexinfo-text: #aaa;

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

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

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

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

    c-[a] { color: #d33682 } /* Keyword.Declaration */
    c-[b] { color: #d33682 } /* Keyword.Type */
    c-[c] { color: #2aa198 } /* Comment */
    c-[d] { color: #2aa198 } /* Comment.Multiline */
    c-[e] { color: #268bd2 } /* Name.Attribute */
    c-[f] { color: #b58900 } /* Name.Tag */
    c-[g] { color: #cb4b16 } /* Name.Variable */
    c-[k] { color: #d33682 } /* Keyword */
    c-[l] { color: #657b83 } /* Literal */
    c-[m] { color: #657b83 } /* Literal.Number */
    c-[n] { color: #268bd2 } /* Name */
    c-[o] { color: #657b83 } /* Operator */
    c-[p] { color: #657b83 } /* Punctuation */
    c-[s] { color: #6c71c4 } /* Literal.String */
    c-[t] { color: #6c71c4 } /* Literal.String.Single */
    c-[u] { color: #6c71c4 } /* Literal.String.Double */
    c-[ch] { color: #2aa198 } /* Comment.Hashbang */
    c-[cp] { color: #2aa198 } /* Comment.Preproc */
    c-[cpf] { color: #2aa198 } /* Comment.PreprocFile */
    c-[c1] { color: #2aa198 } /* Comment.Single */
    c-[cs] { color: #2aa198 } /* Comment.Special */
    c-[kc] { color: #d33682 } /* Keyword.Constant */
    c-[kn] { color: #d33682 } /* Keyword.Namespace */
    c-[kp] { color: #d33682 } /* Keyword.Pseudo */
    c-[kr] { color: #d33682 } /* Keyword.Reserved */
    c-[ld] { color: #657b83 } /* Literal.Date */
    c-[nc] { color: #268bd2 } /* Name.Class */
    c-[no] { color: #268bd2 } /* Name.Constant */
    c-[nd] { color: #268bd2 } /* Name.Decorator */
    c-[ni] { color: #268bd2 } /* Name.Entity */
    c-[ne] { color: #268bd2 } /* Name.Exception */
    c-[nf] { color: #268bd2 } /* Name.Function */
    c-[nl] { color: #268bd2 } /* Name.Label */
    c-[nn] { color: #268bd2 } /* Name.Namespace */
    c-[py] { color: #268bd2 } /* Name.Property */
    c-[ow] { color: #657b83 } /* Operator.Word */
    c-[mb] { color: #657b83 } /* Literal.Number.Bin */
    c-[mf] { color: #657b83 } /* Literal.Number.Float */
    c-[mh] { color: #657b83 } /* Literal.Number.Hex */
    c-[mi] { color: #657b83 } /* Literal.Number.Integer */
    c-[mo] { color: #657b83 } /* Literal.Number.Oct */
    c-[sa] { color: #6c71c4 } /* Literal.String.Affix */
    c-[sb] { color: #6c71c4 } /* Literal.String.Backtick */
    c-[sc] { color: #6c71c4 } /* Literal.String.Char */
    c-[dl] { color: #6c71c4 } /* Literal.String.Delimiter */
    c-[sd] { color: #6c71c4 } /* Literal.String.Doc */
    c-[se] { color: #6c71c4 } /* Literal.String.Escape */
    c-[sh] { color: #6c71c4 } /* Literal.String.Heredoc */
    c-[si] { color: #6c71c4 } /* Literal.String.Interpol */
    c-[sx] { color: #6c71c4 } /* Literal.String.Other */
    c-[sr] { color: #6c71c4 } /* Literal.String.Regex */
    c-[ss] { color: #6c71c4 } /* Literal.String.Symbol */
    c-[fm] { color: #268bd2 } /* Name.Function.Magic */
    c-[vc] { color: #cb4b16 } /* Name.Variable.Class */
    c-[vg] { color: #cb4b16 } /* Name.Variable.Global */
    c-[vi] { color: #cb4b16 } /* Name.Variable.Instance */
    c-[vm] { color: #cb4b16 } /* Name.Variable.Magic */
    c-[il] { color: #657b83 } /* Literal.Number.Integer.Long */
}
</style>
 <body class="h-entry">
  <input id="hidedel" style="display:none" type="checkbox">
  <div class="head">
   <p data-fill-with="logo"></p>
   <h1 class="p-name no-ref" id="title">P1467R6<br>Extended floating-point types and standard names</h1>
   <h2 class="no-num no-toc no-ref heading settled" id="profile-and-date"><span class="content">Published Proposal, <time class="dt-updated" datetime="2021-11-10">2021-11-10</time></span></h2>
   <div data-fill-with="spec-metadata">
    <dl>
     <dt>This version:
     <dd><a class="u-url" href="https://wg21.link/p1467r6">https://wg21.link/p1467r6</a>
     <dt>Issue Tracking:
     <dd><a href="#issues-index">Inline In Spec</a>
     <dt class="editor">Authors:
     <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:dolsen@nvidia.com">David Olsen</a> (<span class="p-org org">NVIDIA</span>)
     <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:ilya.burylov@intel.com">Ilya Burylov</a> (<span class="p-org org">Intel</span>)
     <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:griwes@griwes.info">Michał Dominiak</a> (<span class="p-org org">NVIDIA</span>)
     <dt>Audience:
     <dd>EWG, LEWG
     <dt>Toggle Diffs:
     <dd>
      <label for="hidedel" id="hidedel-label">Hide deleted text</label>
     <dt>Project:
     <dd>ISO/IEC JTC1/SC22/WG21 14882: Programming Language — C++
    </dl>
   </div>
   <div data-fill-with="warning"></div>
   <hr title="Separator for header">
  </div>
  <nav data-fill-with="table-of-contents" id="toc">
   <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
   <ol class="toc" role="directory">
    <li><a href="#abstract"><span class="secno">1</span> <span class="content">Abstract</span></a>
    <li>
     <a href="#revisions"><span class="secno">2</span> <span class="content">Revision history</span></a>
     <ol class="toc">
      <li><a href="#r1"><span class="secno">2.1</span> <span class="content">R0 -> R1 (pre-Cologne)</span></a>
      <li><a href="#r2"><span class="secno">2.2</span> <span class="content">R1 -> R2 (pre-Belfast)</span></a>
      <li><a href="#r3"><span class="secno">2.3</span> <span class="content">R2 -> R3 (pre-Prage)</span></a>
      <li><a href="#r4"><span class="secno">2.4</span> <span class="content">R3 -> R4 (Summer 2020)</span></a>
      <li><a href="#r5"><span class="secno">2.5</span> <span class="content">R4 -> R5 (Fall 2021)</span></a>
      <li><a href="#r6"><span class="secno">2.6</span> <span class="content">R5 -> R6 (Fall 2021)</span></a>
     </ol>
    <li><a href="#motivation"><span class="secno">3</span> <span class="content">Motivation</span></a>
    <li><a href="#c-compat"><span class="secno">4</span> <span class="content">C Compatibility</span></a>
    <li>
     <a href="#core"><span class="secno">5</span> <span class="content">Core language changes</span></a>
     <ol class="toc">
      <li><a href="#core-no-change"><span class="secno">5.1</span> <span class="content">Things that aren’t changing</span></a>
      <li>
       <a href="#extended"><span class="secno">5.2</span> <span class="content">Extended floating-point types</span></a>
       <ol class="toc">
        <li><a href="#extended-reason"><span class="secno">5.2.1</span> <span class="content">Reasoning</span></a>
       </ol>
      <li>
       <a href="#rank"><span class="secno">5.3</span> <span class="content">Conversion rank</span></a>
       <ol class="toc">
        <li><a href="#rank-reason"><span class="secno">5.3.1</span> <span class="content">Reasoning</span></a>
       </ol>
      <li><a href="#promotion"><span class="secno">5.4</span> <span class="content">Promotion</span></a>
      <li>
       <a href="#implicit"><span class="secno">5.5</span> <span class="content">Implicit conversions</span></a>
       <ol class="toc">
        <li><a href="#implicit-reason"><span class="secno">5.5.1</span> <span class="content">Reasoning</span></a>
       </ol>
      <li>
       <a href="#arithmetic"><span class="secno">5.6</span> <span class="content">Usual arithmetic conversions</span></a>
       <ol class="toc">
        <li><a href="#arithmetic-example"><span class="secno">5.6.1</span> <span class="content">Example</span></a>
       </ol>
      <li>
       <a href="#narrow"><span class="secno">5.7</span> <span class="content">Narrowing conversions</span></a>
       <ol class="toc">
        <li><a href="#narrow-constant"><span class="secno">5.7.1</span> <span class="content">Constant values</span></a>
       </ol>
      <li>
       <a href="#overload"><span class="secno">5.8</span> <span class="content">Overload resolution</span></a>
       <ol class="toc">
        <li>
         <a href="#overload-alternate"><span class="secno">5.8.1</span> <span class="content">Alternate proposals</span></a>
         <ol class="toc">
          <li><a href="#overload-smaller"><span class="secno">5.8.1.1</span> <span class="content">Prefer smallest safe conversions</span></a>
          <li><a href="#overload-no-change"><span class="secno">5.8.1.2</span> <span class="content">No change</span></a>
         </ol>
        <li><a href="#overload-comparison"><span class="secno">5.8.2</span> <span class="content">Comparisons</span></a>
       </ol>
      <li><a href="#pointer"><span class="secno">5.9</span> <span class="content">Pointer conversions</span></a>
      <li><a href="#core-test-macro"><span class="secno">5.10</span> <span class="content">Feature test macro</span></a>
     </ol>
    <li>
     <a href="#library"><span class="secno">6</span> <span class="content">Library changes</span></a>
     <ol class="toc">
      <li>
       <a href="#new-names"><span class="secno">6.1</span> <span class="content">Possible new names</span></a>
       <ol class="toc">
        <li><a href="#new-names-standard"><span class="secno">6.1.1</span> <span class="content">Standard/extended floating-point traits</span></a>
        <li><a href="#new-names-conv"><span class="secno">6.1.2</span> <span class="content">Conversion rank trait</span></a>
       </ol>
      <li><a href="#charconv"><span class="secno">6.2</span> <span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>charconv</c-><c- o>></c-></code></span></a>
      <li><a href="#format"><span class="secno">6.3</span> <span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>format</c-><c- o>></c-></code></span></a>
      <li><a href="#iostream"><span class="secno">6.4</span> <span class="content">I/O Streams</span></a>
      <li><a href="#cmath"><span class="secno">6.5</span> <span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>cmath</c-><c- o>></c-></code></span></a>
      <li><a href="#complex"><span class="secno">6.6</span> <span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>complex</c-><c- o>></c-></code></span></a>
      <li><a href="#atomic"><span class="secno">6.7</span> <span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>atomic</c-><c- o>></c-></code></span></a>
      <li><a href="#lib-test-macro"><span class="secno">6.8</span> <span class="content">Feature test macro</span></a>
     </ol>
    <li>
     <a href="#alias"><span class="secno">7</span> <span class="content">Type aliases</span></a>
     <ol class="toc">
      <li><a href="#alias-header"><span class="secno">7.1</span> <span class="content">Header name</span></a>
      <li><a href="#alias-formats"><span class="secno">7.2</span> <span class="content">Supported formats</span></a>
      <li><a href="#alias-alias"><span class="secno">7.3</span> <span class="content">Aliasing standard types</span></a>
      <li><a href="#layout-vs-behavior"><span class="secno">7.4</span> <span class="content">Layout vs. behavior</span></a>
      <li><a href="#test-macros"><span class="secno">7.5</span> <span class="content">Feature test macros</span></a>
      <li>
       <a href="#names"><span class="secno">7.6</span> <span class="content">Names</span></a>
       <ol class="toc">
        <li><a href="#names-c"><span class="secno">7.6.1</span> <span class="content">C compatibility</span></a>
       </ol>
      <li><a href="#literals"><span class="secno">7.7</span> <span class="content">Literal suffixes</span></a>
     </ol>
    <li>
     <a href="#wording"><span class="secno">8</span> <span class="content">Wording</span></a>
     <ol class="toc">
      <li>
       <a href="#wording-core"><span class="secno">8.1</span> <span class="content">Core</span></a>
       <ol class="toc">
        <li><a href="#extended-wording"><span class="secno">8.1.1</span> <span class="content">Extended floating-point types</span></a>
        <li><a href="#rank-wording"><span class="secno">8.1.2</span> <span class="content">Conversion rank</span></a>
        <li><a href="#implicit-wording"><span class="secno">8.1.3</span> <span class="content">Implicit conversions</span></a>
        <li><a href="#arithmetic-wording"><span class="secno">8.1.4</span> <span class="content">Usual arithmetic conversions</span></a>
        <li><a href="#narrow-wording"><span class="secno">8.1.5</span> <span class="content">Narrowing conversions</span></a>
        <li><a href="#overload-wording"><span class="secno">8.1.6</span> <span class="content">Overload resolution</span></a>
       </ol>
      <li>
       <a href="#wording-library"><span class="secno">8.2</span> <span class="content">Library</span></a>
       <ol class="toc">
        <li><a href="#stdfloat-wording"><span class="secno">8.2.1</span> <span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>stdfloat</c-><c- o>></c-></code></span></a>
        <li><a href="#charconv-wording"><span class="secno">8.2.2</span> <span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>charconv</c-><c- o>></c-></code></span></a>
        <li>
         <a href="#iostream-wording"><span class="secno">8.2.3</span> <span class="content">I/O Streams</span></a>
         <ol class="toc">
          <li><a href="#ostream-wording"><span class="secno">8.2.3.1</span> <span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>ostream</c-><c- o>></c-></code></span></a>
          <li><a href="#istream-wording"><span class="secno">8.2.3.2</span> <span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>istream</c-><c- o>></c-></code></span></a>
         </ol>
        <li><a href="#cmath-wording"><span class="secno">8.2.4</span> <span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>cmath</c-><c- o>></c-></code></span></a>
        <li><a href="#complex-wording"><span class="secno">8.2.5</span> <span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>complex</c-><c- o>></c-></code></span></a>
        <li><a href="#atomic-wording"><span class="secno">8.2.6</span> <span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>atomic</c-><c- o>></c-></code></span></a>
        <li><a href="#test-macros-wording"><span class="secno">8.2.7</span> <span class="content">Feature test macros</span></a>
       </ol>
     </ol>
    <li>
     <a href="#references"><span class="secno"></span> <span class="content">References</span></a>
     <ol class="toc">
      <li><a href="#informative"><span class="secno"></span> <span class="content">Informative References</span></a>
     </ol>
    <li><a href="#issues-index"><span class="secno"></span> <span class="content">Issues Index</span></a>
   </ol>
  </nav>
  <main>
   <h2 class="heading settled" data-level="1" id="abstract"><span class="secno">1. </span><span class="content">Abstract</span><a class="self-link" href="#abstract"></a></h2>
   <p>Allow implementations to define <em>extended floating-point types</em> in addition to the three standard floating-point types.  Define rules for how the extended floating-point types interact with each other and with other types without changing the behavior of the existing standard floating-point types.  Specify the rules for type conversions, arithmetic conversions, narrowing conversions, and overload resolution in a way that strikes a balance between behaving like existing types and encouraging safe code.  Specify the necessary library support, mostly additional overloads for functions that take floating-point arguments, for the extended floating-point types.</p>
   <p>Define an optional set of <code class="highlight"><c- o>&lt;</c-><c- n>cstdint</c-><c- o>></c-></code>-style type aliases for floating-point types matching specific, well-known floating-point layouts.</p>
   <h2 class="heading settled" data-level="2" id="revisions"><span class="secno">2. </span><span class="content">Revision history</span><a class="self-link" href="#revisions"></a></h2>
   <h3 class="heading settled" data-level="2.1" id="r1"><span class="secno">2.1. </span><span class="content">R0 -> R1 (pre-Cologne)</span><a class="self-link" href="#r1"></a></h3>
   <p>Applied guidance from <a href="http://wiki.edg.com/bin/view/Wg21kona2019/SG6MinutesP1468">SG6</a> in Kona 2019:</p>
   <ol>
    <li data-md>
     <p>Make the floating-point conversion rank not ordered between types with overlapping (but not subsetted) ranges of finite values.  This makes the ranking a partial order.</p>
    <li data-md>
     <p>Narrowing conversions are now based on floating-point conversion rank instead of ranges of finite values, which preservesthe current narrowing conversions relations between standard floating-point types; it also interacts favorably with the rank being a partial ordering.</p>
    <li data-md>
     <p>Operations that deal with floating-point types whose conversion ranks are unordered are now ill-formed.</p>
    <li data-md>
     <p>The relevant parts of the guidance have been applied to the library wording section as well.</p>
   </ol>
   <p>Afterwards, applied suggestions from <a href="http://wiki.edg.com/bin/view/Wg21kona2019/P1467">EWGI</a> in Kona 2019 (this modifies some of the points above):</p>
   <ol>
    <li data-md>
     <p>Apply the suggestion to make types where one has a wider range of finite values, but a lower precision than the other, unordered in their conversion rank, and therefore make operations that mix them ill-formed. The motivating example was IEEE-754 <code class="highlight"><c- n>binary16</c-></code> and <code class="highlight"><c- n>bfloat16</c-></code>; see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1467r1.html#rank">Floating-point conversion rank</a> for more details. This change also caused this paper to drop the term "range of finite values", since the modified semantics are better expressed in terms of sets of values of the types.</p>
    <li data-md>
     <p>Add a change to narrowing conversions, to only allow exact conversions to happen.</p>
    <li data-md>
     <p>Explicitly list parts of the language that are not changed by this paper; provide a more detailed analysis of the standard library impact.</p>
   </ol>
   <h3 class="heading settled" data-level="2.2" id="r2"><span class="secno">2.2. </span><span class="content">R1 -> R2 (pre-Belfast)</span><a class="self-link" href="#r2"></a></h3>
   <p>Changes based on feedback in Cologne from <a href="http://wiki.edg.com/bin/view/Wg21cologne2019/SG6P1468">SG6</a>, <a href="http://wiki.edg.com/bin/view/Wg21cologne2019/P1467">LEWGI</a>, and <a href="http://wiki.edg.com/bin/view/Wg21cologne2019/P1468">EWGI</a>.  Further changes came from further development of the paper by the authors, especially <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1467r2.html#overload">overload resolution</a>.</p>
   <ul>
    <li data-md>
     <p>Revised floating-point <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1467r2.html#promotion">promotion</a> rules.  Removed all promotions other than <code class="highlight"><c- b>float</c-></code> to <code class="highlight"><c- b>double</c-></code>.  Added wording for promoting values passed to varargs functions.</p>
    <li data-md>
     <p>Added the section on <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1467r2.html#implicit">implicit conversions</a>.</p>
    <li data-md>
     <p>Added the section on <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1467r2.html#overload">overload resolution</a>.</p>
    <li data-md>
     <p>Added the section about <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1467r2.html#core-test-macro">feature test macros</a>.</p>
    <li data-md>
     <p>Added the sections about the possibility of new <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1467r2.html#new-names">library traits</a>.</p>
    <li data-md>
     <p>Changed the wording for the <code class="highlight"><c- n>abs</c-></code> function in the <code class="highlight"><c- o>&lt;</c-><c- n>cmath</c-><c- o>></c-></code> section.</p>
    <li data-md>
     <p>Added constraints to the I/O streams overloads for <code class="highlight"><c- n>complex</c-></code> to only support standard floating-point types.</p>
    <li data-md>
     <p>Added the section about possible changes to <code class="highlight"><c- o>&lt;</c-><c- n>atomic</c-><c- o>></c-></code>.</p>
   </ul>
   <h3 class="heading settled" data-level="2.3" id="r3"><span class="secno">2.3. </span><span class="content">R2 -> R3 (pre-Prage)</span><a class="self-link" href="#r3"></a></h3>
   <p>Changes based on feedback in Belfast from <a href="http://wiki.edg.com/bin/view/Wg21belfast/P1467-EWG">EWG</a>.</p>
   <ul>
    <li data-md>
     <p>Change the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1467r3.html#overload">overload resolution</a> rules, removing the rule that prefers one standard conversion over another based on conversion rank.  Replace it with a rule that prefers one standard conversion over another only when the two types have the same representation.</p>
    <li data-md>
     <p>As a result of the overload resolution change, change floating-point <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1467r3.html#promotion">promotion</a> so that any type smaller than <code class="highlight"><c- b>double</c-></code> promotes to <code class="highlight"><c- b>double</c-></code>.</p>
    <li data-md>
     <p>Allow implicit conversions between pointer types that point to floating-point types with the same representation.</p>
   </ul>
   <h3 class="heading settled" data-level="2.4" id="r4"><span class="secno">2.4. </span><span class="content">R3 -> R4 (Summer 2020)</span><a class="self-link" href="#r4"></a></h3>
   <p>Merge <a href="http://wg21.link/p1468r3">P1468</a> into P1467.  The two papers were separate proposals when first written.  But over time they have become intertwined, with design decisions in one paper affecting the feasibility of the other.  So the two papers are being merged into a single proposal in P1467R4.</p>
   <p>Changes based on feedback in Prague from EWG, where the discussion was all about what the goals of the proposal should be.  The group settled on a set of design decisions (see the <a href="https://github.com/cplusplus/papers/issues/227#issuecomment-584655443">poll results</a>) that strike a balance between the existing behavior of arithmetic types and a "safe by default" strategy.</p>
   <p>Changes between <a href="http://wg21.link/p1467r3">P1467R3</a> and P1647R4:</p>
   <ul>
    <li data-md>
     <p>Add section <a href="#c-compat">§ 4 C Compatibility</a></p>
    <li data-md>
     <p>Revert the rules for floating-point <a href="#promotion">§ 5.4 Promotion</a> back to what they were in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1467r2.html#promotion">P1647R2</a>, which is essentially unchanged from the current C++ standard.  This was necessitated by changes to the overload resolution rules.</p>
    <li data-md>
     <p>Resolve the open issue of <a href="#implicit">§ 5.5 Implicit conversions</a>.  In R3, it was undecided if potentially lossy conversions should be implicit.  EWG in Prague was strongly in favor of requiring lossy conversions to be explicit.  The section on implicit conversions now reflects that guidance.</p>
    <li data-md>
     <p>Revert the rules for <a href="#overload">§ 5.8 Overload resolution</a> back to what they were in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1467r2.html#overload">P1647R2</a>, with a small fix to the proposed wording changes.  Two alternate ideas for overload resolution are now listed.</p>
    <li data-md>
     <p>Withdraw the proposed change for <a href="#pointer">§ 5.9 Pointer conversions</a>.</p>
   </ul>
   <p>Changes to the content of <a href="http://wg21.link/p1468r3">P1468R3</a> as it was merged into P1647R4:</p>
   <ul>
    <li data-md>
     <p>Changed the proposed <a href="#literals">§ 7.7 Literal suffixes</a> to match what will be available in C2x.</p>
   </ul>
   <h3 class="heading settled" data-level="2.5" id="r5"><span class="secno">2.5. </span><span class="content">R4 -> R5 (Fall 2021)</span><a class="self-link" href="#r5"></a></h3>
   <p>Rebase wording to C++20.</p>
   <p>Separate the design and wording sections, with links between them.</p>
   <p>Improve the section on C Compatibility, adding more discussion about the use of different names in the two languages and a section about differences in usual arithmetic conversions.</p>
   <p>Remove the part of the proposal that promoted types smaller than <code class="highlight"><c- b>double</c-></code> to <code class="highlight"><c- b>double</c-></code> when passed to varargs functions.</p>
   <p>Add more explanation to the section about overload resolution.</p>
   <p>Fill in the section about <code class="highlight"><c- o>&lt;</c-><c- n>format</c-><c- o>></c-></code>.</p>
   <p>Add support for I/O Streams of extended floating-point types that are no larger than <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>.</p>
   <p>Add background information for the sections on <code class="highlight"><c- o>&lt;</c-><c- n>charconv</c-><c- o>></c-></code> and <code class="highlight"><c- o>&lt;</c-><c- n>cmath</c-><c- o>></c-></code>.</p>
   <p>Decide on one set of names, <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float</c-><em><c- n>N</c-></em><c- n>_t</c-></code>, for the type aliases of types with well-known formats.</p>
   <h3 class="heading settled" data-level="2.6" id="r6"><span class="secno">2.6. </span><span class="content">R5 -> R6 (Fall 2021)</span><a class="self-link" href="#r6"></a></h3>
   <p>Based on discussions on SG22 and EWG mailing lists and an SG22/CFP teleconference, make a slight change to usual arithmetic conversions to match C23’s behavior.  The best way to do that is to change the definition of conversion rank, splitting it into rank and subrank.  This leads to very slight changes to implicit conversions and narrowing conversions.  The description and wording for all these sections has changed, though the changes that would be noticed by a programmer are very minor.  The change to conversion rank also results in changes to the wording for some library features, though no change in behavior.</p>
   <p>Change the overload resolution section significantly, switching the proposal from "prefer smallest safe conversion" to "prefer same conversion rank."</p>
   <p>No longer propose adding any new type traits.  The discussion is still in the paper, but the recommendation is for no change.  See <a href="#new-names">§ 6.1 Possible new names</a></p>
   <p>Choose <code class="highlight"><c- o>&lt;</c-><c- n>stdfloat</c-><c- o>></c-></code> as the name of the header for the new type aliases.</p>
   <p>Add a paragraph to <a href="#names-c">§ 7.6.1 C compatibility</a> discussing the implications of C23 names <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em><c- n>_t</c-></code>.</p>
   <p>Request polls from LEWG about whether or not the <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em></code> names should be required to be available in C++, and about whether the literal suffixes should be a language feature or a library feature.</p>
   <p>Add preliminary wording for the type aliases and their literal suffixes.</p>
   <h2 class="heading settled" data-level="3" id="motivation"><span class="secno">3. </span><span class="content">Motivation</span><a class="self-link" href="#motivation"></a></h2>
   <p>16-bit floating-point support is becoming more widely available in both hardware (ARM CPUs, NVIDIA GPUs, and, as of recently, Intel CPUs) and software (OpenGL, CUDA, and LLVM IR).  Programmers wanting to take advantage of 16-bit floating-point support have been stymied by the lack of built-in compiler support for the type.  A common workaround is to define a class type with all of the conversion operators and overloaded arithmetic operators to make it behave as much as possible like a built-in type.  But that approach is cumbersome and incomplete, requiring inline assembly or other compiler-specific magic to generate efficient code.</p>
   <p>The problem of efficiently using newer floating-point types that haven’t traditionally been supported can’t be solved through user-defined libraries.  A possible solution of an implementation changing <code class="highlight"><c- b>float</c-></code> to be a 16-bit type would be unpopular because users want support for newer floating-point types in addition to the standard types, and because users have come to expect <code class="highlight"><c- b>float</c-></code> and <code class="highlight"><c- b>double</c-></code> to be 32- and 64-bit types and have lots of existing code written with that assumption.</p>
   <p>This problem is worth solving, and there is no viable solution under the current standard.  So changing the core language in an extensible and backward-compatible way is appropriate.  Providing a standard way for implementations to support 16-bit floating-point types will result in better code, more portable code, and wider use of those types.</p>
   <p>While deciding what names to give to the 16-bit floating-point types, it was decided that C++ would benefit from having standard names for other larger floating-point types that are commonly used.  Having names for specific floating-point formats allows users to more clearly specify their intent.  If a user writes code that is designed for an IEEE 64-bit binary floating-point type, the code is more clear if it uses a name that is guaranteed to be IEEE 64-bit, and the failure mode is more immediate (a compilation error) if the code is ported to a system where an IEEE 64-bit type is not available.  This part of the proposal is a revival, with major modifications, of <a data-link-type="biblio" href="#biblio-n1703">[N1703]</a>, which in 2013 proposed adding typedefs for fixed-layout floating-point types to both C and C++, but was not adopted by either language.</p>
   <p>The motivation for the current approach of extended floating-point types comes from discussion of the previous paper <a data-link-type="biblio" href="#biblio-p0192">[P0192]</a>.  That proposal’s single new standard type of <code class="highlight"><c- b>short</c-> <c- b>float</c-></code> was considered insufficient, preventing the use of both IEEE-754 16-bit and <code class="highlight"><c- n>bfloat16</c-></code> in the same application.  When that proposal was rejected in November 2018, the current, more expansive, proposal was developed.  It is not feasible to predict which floating-point types, or even how many different types, will be used in the future, so this proposal allows for as many types as the implementation sees fit.</p>
   <h2 class="heading settled" data-level="4" id="c-compat"><span class="secno">4. </span><span class="content">C Compatibility</span><a class="self-link" href="#c-compat"></a></h2>
   <p>The C standards committee, WG14, has added a new annex containing significant extensions to floating-point support to the next revision of the C standard, C23.  The annex has not been merged into the C draft standard yet, but text that is very close to what will be in the standard is available in <a data-link-type="biblio" href="#biblio-wg14-n2601">[WG14-N2601]</a>.  The changes being worked on for C are mostly compatible with the changes proposed for C++ in this proposal.  Users will be able to write code that that uses IEEE floating-point types, including 16-bit binary, that compiles and behaves the same in both languages.</p>
   <p>The C proposal adds optional types <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em></code>, where <em>N</em> is 16, 32, 64, 128, or greater than 128 and divisible by 32. <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em></code> is an IEEE binary floating-point type with the given size.  These types will have the same representation as the named aliases proposed <a href="#alias-formats">below</a>.  (Except that C does not define a type for the non-IEEE <code class="highlight"><c- n>bfloat16</c-></code> format.)</p>
   <p>There are two areas of divergence between the C and C++ proposals that are worth discussing:</p>
   <ol>
    <li data-md>
     <p>Names: The C proposal uses <code class="highlight"><c- n>_Float16</c-></code>, <code class="highlight"><c- n>_Float32</c-></code>, <code class="highlight"><c- n>_Float64</c-></code>, and <code class="highlight"><c- n>_Float128</c-></code> as optional keywords naming the IEEE types.  This paper proposes type aliases in the <code class="highlight"><c- n>std</c-></code> namespace, <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float16_t</c-></code>, <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float32_t</c-></code>, <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code>, and <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float128_t</c-></code>.  Since C++ likes to have all its library names in namespace <code class="highlight"><c- n>std</c-></code>, and C does not have namespace <code class="highlight"><c- n>std</c-></code> at all, it seems unavoidable that there will be some divergence in this area.  See <a href="#names-c">§ 7.6.1 C compatibility</a> for discussion of the impact of this difference and some possible ways to deal with it.</p>
    <li data-md>
     <p>Implicit conversions: In this C++ proposal, narrowing conversions between floating-point types have to be explicit. (See <a href="#implicit">§ 5.5 Implicit conversions</a>)  In the C proposal, conversions between floating-point types can be done implicitly, even when they are narrowing and potentially lossy.  This will result in floating-point code that will compile as C but not as C++.  While this divergence is unfortunate, it is acceptable because conversions involving extended floating-point types that compile successfully in both languages will behave the same in both languages.</p>
   </ol>
   <p>Previously, there was also a difference in usual arithmetic conversions. This proposal and C have always agreed on the results of a binary operator when at least one of the operands is a floating-point type and the two types have different representations. However, when the two operands were different floating-point types with the same representation, this paper proposed that <code class="highlight"><c- b>double</c-> <c- o>+</c-> <c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code> (assuming they have the same representation) would have type <code class="highlight"><c- b>double</c-></code>, while in C, <code class="highlight"><c- b>double</c-> <c- o>+</c-> <c- n>_Float64</c-></code> has type <code class="highlight"><c- n>_Float64</c-></code>. The rationale for the C rules is that if a user buys into the fixed-layout types explicitly, we should preserve that decision through expressions and library function calls.</p>
   <p>This matter was discussed during an SG22 meeting, and a consensus was reached that this paper should instead adopt the C rules; now, with this revision, the result of <code class="highlight"><c- b>double</c-> <c- o>+</c-> <c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code> is <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code>.</p>
   <p>(C23 will define the term <em>extended floating types</em> (<a data-link-type="biblio" href="#biblio-wg14-n2601">[WG14-N2601]</a> section X.2.3) to mean something completely different from the term <em>extended floating-point types</em> as used in this paper (<a href="#extended">§ 5.2 Extended floating-point types</a>).  The terms are only used in specifications and do not appear in user code, so any confusion will hopefully be limited to committee members and not be a problem in the broader programming community.  It might be worth the effort to come up with a different name to use in the C++ standard, since "extended" fits the C usage better than the C++ usage.)</p>
   <h2 class="heading settled" data-level="5" id="core"><span class="secno">5. </span><span class="content">Core language changes</span><a class="self-link" href="#core"></a></h2>
   <h3 class="heading settled" data-level="5.1" id="core-no-change"><span class="secno">5.1. </span><span class="content">Things that aren’t changing</span><a class="self-link" href="#core-no-change"></a></h3>
   <p>It is currently implementation-defined whether or not the floating-point types support infinity and NaN.  That is not changing.  That feature will still be implementation-defined, even for extended floating-point types.</p>
   <p>The radix of the exponent of each floating-point type is currently implementation-defined.  That is not changing.  This paper will make it easier for the radix of extended floating-point types to be different from the radix of the standard types, allowing implementations to support decimal floating-point while the standard floating-point types remain binary floating-point types.</p>
   <h3 class="heading settled" data-level="5.2" id="extended"><span class="secno">5.2. </span><span class="content">Extended floating-point types</span><a class="self-link" href="#extended"></a></h3>
   <p><i>Wording: <a href="#extended-wording">§ 8.1.1 Extended floating-point types</a></i></p>
   <p>In addition to the three standard floating-point types, <code class="highlight"><c- b>float</c-></code>, <code class="highlight"><c- b>double</c-></code>, and <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>, implementations may define any number of <em>extended floating-point types</em>, similar to how implementations may define extended integer types.</p>
   <p>An extended floating-point type may have the same representation and the same set of values as a standard floating-point type.  But the extended floating-point type is still a separate type, and is not just an alias for the standard type.  See <a href="#alias-alias">§ 7.3 Aliasing standard types</a> for the reasoning behind this decision.  It is expected that this will be a common occurrence in implementations that support extended floating-point types.</p>
   <h4 class="heading settled" data-level="5.2.1" id="extended-reason"><span class="secno">5.2.1. </span><span class="content">Reasoning</span><a class="self-link" href="#extended-reason"></a></h4>
   <p>The set of floating-point types that have hardware support is not possible to accurately predict years into the future.  The standard needs to provide an extensible solution so that implementations can adapt to changing hardware without having to modify the standard.</p>
   <h3 class="heading settled" data-level="5.3" id="rank"><span class="secno">5.3. </span><span class="content">Conversion rank</span><a class="self-link" href="#rank"></a></h3>
   <p><i>Wording: <a href="#rank-wording">§ 8.1.2 Conversion rank</a></i></p>
   <p>Define <em>floating-point conversion rank</em> to mimic in some ways the existing integer conversion rank.  Floating-point conversion rank is defined in terms of the sets of values that the types can represent.  If the set of values of type <code class="highlight"><c- n>T</c-></code> is a strict superset of the set of values of type <code class="highlight"><c- n>U</c-></code>, then <code class="highlight"><c- n>T</c-></code> has a higher conversion rank than <code class="highlight"><c- n>U</c-></code>.  If the sets of values of two types are neither a subset nor a superset of each other, then the conversion ranks of the two types are unordered.  Two standard floating-point types always have different conversion ranks.  But two extended floating-point types, or an extended floating-point type and a standard floating-point type, with the same set of values have the same conversion rank.  Floating-point conversion rank forms a partial order, not a total order; this is the biggest difference from integer conversion rank.</p>
   <p>When two types have the same conversion rank, they are still ordered by a conversion subrank.  The subrank forms a total order among types with the same rank.  The IEEE types listed in <a href="#alias-formats">§ 7.2 Supported formats</a> have a subrank greater than any standard type with the same rank.  The subrank order is otherwise implementation defined.</p>
   <p>When two or more standard types have the same representation, then any extended types with that same representation have the same conversion rank as <code class="highlight"><c- b>double</c-></code>.</p>
   <h4 class="heading settled" data-level="5.3.1" id="rank-reason"><span class="secno">5.3.1. </span><span class="content">Reasoning</span><a class="self-link" href="#rank-reason"></a></h4>
   <p>Splitting the ranking of floating-point types into rank and subrank simplifies the wording in other places in the standard.  Several places where the standard wording would have had to say something like "greater conversion rank or same set of values" can say instead "greater or equal conversion rank."  The phrase "set of values" is needed only when defining conversion rank and subrank, and is not used anywhere else when discussing extended floating-point types.</p>
   <p>The rules for subrank order enable C++ and C23 to have the same usual arithmetic conversion rules.  In C23, types that represent IEEE interchange formats (named <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em></code> in C23) are preferred over standard types with the same representation, and standard types are preferred over types that represent IEEE extended formats (named <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em><c- n>x</c-></code> in C23) with the same representation.  The IEEE types listed in <a href="#alias-formats">§ 7.2 Supported formats</a> represent IEEE interchange formats, so their subrank is defined to be greater than the subrank of a standard type.  This proposal doesn’t try to classify any other extended floating-point types as IEEE interchange formats, or IEEE extended formats, or as anything else.  So the rest of subrank ordering is implementation defined, leaving it up to quality-of-implementation to match C’s behavior if there are any C++ extended floating-point types that represent IEEE extended formats.</p>
   <p>Earlier versions of this proposal used the range of finite values to define conversion rank, and had the conversion rank be a total ordering.  Discussions in <a href="http://wiki.edg.com/bin/view/Wg21kona2019/SG6MinutesP1468">SG6</a> in Kona 2019 pointed out that that definition resulted in undesirable interactions between IEEE <code class="highlight"><c- n>binary16</c-></code> with 5-bit exponent and 10-bit mantissa, and <code class="highlight"><c- n>bfloat16</c-></code> with 8-bit exponent and 7-bit mantissa. <code class="highlight"><c- n>bfloat16</c-></code> has a much larger finite range, so it would have a higher conversion rank under the old rules.  Mixing <code class="highlight"><c- n>binary16</c-></code> and <code class="highlight"><c- n>bfloat16</c-></code> in an arithmetic operation would result in the <code class="highlight"><c- n>binary16</c-></code> value being converted to <code class="highlight"><c- n>bfloat16</c-></code> despite the loss of three bits of precision.  This implicit loss of precision was worrisome, so the definition of conversion rank was changed so that the usual arithmetic conversions between two floating-point values always preserves the value exactly.</p>
   <p>For the purposes of conversion rank, infinity and NaN are treated just like any other values.  If type <code class="highlight"><c- n>T</c-></code> supports infinity and type <code class="highlight"><c- n>U</c-></code> does not, then <code class="highlight"><c- n>U</c-></code> can never have a greater conversion rank than <code class="highlight"><c- n>T</c-></code>, even if <code class="highlight"><c- n>U</c-></code> has a bigger range and a longer mantissa.</p>
   <h3 class="heading settled" data-level="5.4" id="promotion"><span class="secno">5.4. </span><span class="content">Promotion</span><a class="self-link" href="#promotion"></a></h3>
   <p>Floating-point promotions are unchanged.  For backward compatibility, a conversion from <code class="highlight"><c- b>float</c-></code> to <code class="highlight"><c- b>double</c-></code> is considered to be a promotion rather than a standard conversion during overload resolution.  But no other floating-point conversions are promotions.  There are no changes to the wording for floating-point promotions.</p>
   <p>Earlier versions of this proposal promoted function arguments of extended floating-point types that were smaller than <code class="highlight"><c- b>double</c-></code> (as defined by conversion rank) to <code class="highlight"><c- b>double</c-></code> when passed as the ellipsis part of a varargs function.  The C committee considered this behavior, and for a while it was also a part of the proposed changes for C23.  But WG14 argued against this, saying that promotion from <code class="highlight"><c- b>float</c-></code> to <code class="highlight"><c- b>double</c-></code> was a holdover from K&amp;R C and should not be extended to new types.  This part of the C23 proposal for floating-point was withdrawn.  To minimize divergence between C and C++, this was also withdrawn from the C++ proposal.</p>
   <h3 class="heading settled" data-level="5.5" id="implicit"><span class="secno">5.5. </span><span class="content">Implicit conversions</span><a class="self-link" href="#implicit"></a></h3>
   <p><i>Wording: <a href="#implicit-wording">§ 8.1.3 Implicit conversions</a></i></p>
   <p>A conversion between two floating-point types, when at least one of the types is an extended floating-point type, is implicit only if the destination type has greater or equal conversion rank than the source type.  Any implicit conversion will be lossless and preserve the value exactly.  Any conversion that is potentially lossy must be explicit.</p>
   <p>Not all lossless conversions will be implicit, but the situations where a lossless conversion has to be explicit will be relatively rare.  It will only happen when two standard types have the same representation and there is also an extended type with that representation.  For example, when <code class="highlight"><c- b>double</c-></code> and <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> are both IEEE 64-bit types, the conversion from <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> to <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code> would be from a higher conversion rank to a lower rank and therefore is not an implicit conversion, even though the two types have the set of values.</p>
   <p>The conversion rules for standard floating-point types can’t be changed without breaking existing code, so conversions from <code class="highlight"><c- b>double</c-></code> to <code class="highlight"><c- b>float</c-></code> and from <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> to <code class="highlight"><c- b>double</c-></code> or <code class="highlight"><c- b>float</c-></code> will still be implicit.</p>
   <h4 class="heading settled" data-level="5.5.1" id="implicit-reason"><span class="secno">5.5.1. </span><span class="content">Reasoning</span><a class="self-link" href="#implicit-reason"></a></h4>
   <p>The standard currently allows implicit conversions between any arithmetic types (except during brace init, when narrowing conversion rules apply), even if the conversion could result in a loss of information.  This rule makes it too easy to write buggy code.  Changing rules for existing types is not feasible because it would be a major breaking change.  But the rules can be changed when types are used in new ways, as was done for brace init and narrowing conversions, or for new types, as is proposed here.</p>
   <p>This was discussed in EWG in Prague, and there was consensus to limit implicit conversions for extended floating-point types.  "Extended floating point types match the current C++ rules for conversions." 2-3-6-19-3  "Implicit conversions are only allowed if non-narrowing." 14-15-8-0-1</p>
   <h3 class="heading settled" data-level="5.6" id="arithmetic"><span class="secno">5.6. </span><span class="content">Usual arithmetic conversions</span><a class="self-link" href="#arithmetic"></a></h3>
   <p><i>Wording: <a href="#arithmetic-wording">§ 8.1.4 Usual arithmetic conversions</a></i></p>
   <p>The proposed usual arithmetic conversions for floating-point types are based on the floating-point conversion rank, similar to integer arithmetic conversions.  But because floating-point conversions are a partial ordering, there may be some expressions where neither operand will be converted to the other’s type.  It is proposed that these situations are ill-formed.  For the cases where two different types have the same conversion rank, the floating-point conversion subrank is used to determine the result type.</p>
   <h4 class="heading settled" data-level="5.6.1" id="arithmetic-example"><span class="secno">5.6.1. </span><span class="content">Example</span><a class="self-link" href="#arithmetic-example"></a></h4>
   <p class="note" role="note"><span>Note:</span> In all the examples in this paper, <code class="highlight"><c- b>float</c-></code> and <code class="highlight"><c- b>double</c-></code> are IEEE 32-bit and 64-bit types, <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float</c-><i><c- n>N</c-></i><c- n>_t</c-></code> is an extended floating-point type for IEEE <em>N</em>-bit, and <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>bfloat16_t</c-></code> is <code class="highlight"><c- n>bfloat16</c-></code>.</p>
<pre class="highlight"><c- b>float</c-> <c- n>f32</c-> <c- o>=</c-> <c- mf>1.0</c-><c- p>;</c->
<c- n>std</c-><c- o>::</c-><c- n>float16_t</c-> <c- n>f16</c-> <c- o>=</c-> <c- mf>2.0</c-><c- p>;</c->
<c- n>std</c-><c- o>::</c-><c- n>bfloat16_t</c-> <c- n>b16</c-> <c- o>=</c-> <c- mf>3.0</c-><c- p>;</c->
<c- n>f32</c-> <c- o>+</c-> <c- n>f16</c-><c- p>;</c-> <c- c1>// okay, f16 converted to "float", result type is "float"</c->
<c- n>f32</c-> <c- o>+</c-> <c- n>b16</c-><c- p>;</c-> <c- c1>// okay, b16 converted to "float", result type is "float"</c->
<c- n>f16</c-> <c- o>+</c-> <c- n>b16</c-><c- p>;</c-> <c- c1>// error, neither type can convert to the other via arithmetic conversions</c->
</pre>
   <h3 class="heading settled" data-level="5.7" id="narrow"><span class="secno">5.7. </span><span class="content">Narrowing conversions</span><a class="self-link" href="#narrow"></a></h3>
   <p><i>Wording: <a href="#narrow-wording">§ 8.1.5 Narrowing conversions</a></i></p>
   <p>A narrowing conversion is a conversion from a type with a higher floating-point conversion rank to a type with a lower conversion rank, or a conversion between two types with unordered conversion rank.</p>
   <p>When extended floating-point types are involved, the rules for what is a non-narrowing conversion are exactly the same as the rules for an implicit conversion.  A narrowing conversion cannot be done implicitly even in contexts where the narrowing conversion rules don’t apply.</p>
   <p>To preserve backward compatibility, the rules for non-narrowing conversions and implicit conversions are different when both types are standard types.  Conversions from <code class="highlight"><c- b>double</c-></code> to <code class="highlight"><c- b>float</c-></code> and from <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> to <code class="highlight"><c- b>double</c-></code> are still narrowing conversions.</p>
   <h4 class="heading settled" data-level="5.7.1" id="narrow-constant"><span class="secno">5.7.1. </span><span class="content">Constant values</span><a class="self-link" href="#narrow-constant"></a></h4>
   <p>This proposal preserves the existing wording in [dcl.init.list] p7.2, "except where the source is a constant expression and the actual value after conversion is within the range of values that can be represented (even if it cannot be represented exactly)."  A reasonable argument could be made that this constant value exception should not apply to extended floating-point types.  But the authors are not in favor of that change. It would introduce an inconsistency between standard and extended types. It would cause <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float16_t</c-> <c- n>x</c-><c- p>{</c-><c- mf>2.1</c-><c- p>};</c-></code> to be a narrowing conversion because <code class="highlight"><c- mf>2.1</c-></code> cannot be represented exactly in binary floating-point representations.</p>
   <h3 class="heading settled" data-level="5.8" id="overload"><span class="secno">5.8. </span><span class="content">Overload resolution</span><a class="self-link" href="#overload"></a></h3>
   <p><i>Wording: <a href="#overload-wording">§ 8.1.6 Overload resolution</a></i></p>
   <p>When comparing conversion sequences that involve floating-point conversions, prefer conversions that are value-preserving, and prefer conversions to other floating-point types with the same conversion rank if value-preserving conversions are ambiguous.</p>
   <p>This is a departure from the previously proposed overload resolution rules, one that improved Evolution consensus by removing a strong opposition to the previously proposed changes in overload resolution. The currently proposed rule has previously been described in the paper as one of the possible alternative designs, though it was never discussed extensively in earlier meetings.</p>
   <p>With the proposed change to implicit conversions, preferring value-preserving conversions over lossy conversions comes for free, since overloads with lossy conversions won’t be viable candidates (except when both types are standard floating-point types).</p>
   <p>Preferring a conversion to a type with the same conversion rank comes from the desire for a function call to be well-formed rather than ambiguous when an overload with a matching representation, but not a matching type, exists.</p>
<pre class="highlight"><code class="highlight"><c- b><c- b>void</c-></c-> <c- nf><c- nf>f</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>float32_t</c-></c-><c- p><c- p>);</c-></c->
<c- b><c- b>void</c-></c-> <c- nf><c- nf>f</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>float64_t</c-></c-><c- p><c- p>);</c-></c->

<c- n><c- n>f</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>float16_t</c-></c-><c- p><c- p>(</c-></c-><c- mf><c- mf>1.0</c-></c-><c- p><c- p>));</c-></c-> <c- c1><c- c1>// ambiguous</c-></c->
<c- n><c- n>f</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>float</c-></c-><c- p><c- p>(</c-></c-><c- mf><c- mf>2.0</c-></c-><c- p><c- p>));</c-></c->          <c- c1><c- c1>// calls std::float32_t, because same conversion rank</c-></c->
<c- n><c- n>f</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>double</c-></c-><c- p><c- p>(</c-></c-><c- mf><c- mf>3.0</c-></c-><c- p><c- p>));</c-></c->         <c- c1><c- c1>// calls std::float64_t, only viable candidate</c-></c->
</code></pre>
   <p>See <a href="#overload-comparison">§ 5.8.2 Comparisons</a> for more examples.</p>
   <h4 class="heading settled" data-level="5.8.1" id="overload-alternate"><span class="secno">5.8.1. </span><span class="content">Alternate proposals</span><a class="self-link" href="#overload-alternate"></a></h4>
   <p>Below, we present two alternate designs: the first one describes what used to be the proposal in the paper, and one that discusses the pitfalls of making no changes to overload resolution rules.</p>
   <p>This issue was debated in EWG in Prague, and the first alternative below was favored, but not by enough to consider it consensus given the significant number of neutral and strongly-against votes.  "Prefer smaller safe conversions over larger safe conversions in overload resolution." 3-14-10-0-7</p>
   <p>The issue was discussed again on a Language Evolution <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1467-24-June-2020">telecon</a> in June 2020.  There were two polls, one a repeat of Prague’s poll, with conflicting results.  "Prefer smaller safe conversions over larger safe conversions in overload resolution (proposal in the paper, polled in prague)." 0-8-3-4-1  "Overload resolution should stay the same, two different safe conversions should remain ambiguous (keep the current status-quo)." 5-4-3-4-1</p>
   <h5 class="heading settled" data-level="5.8.1.1" id="overload-smaller"><span class="secno">5.8.1.1. </span><span class="content">Prefer smallest safe conversions</span><a class="self-link" href="#overload-smaller"></a></h5>
   <p>When comparing conversion sequences that involve floating-point conversions, prefer conversions that are value-preserving, and prefer conversions to lower conversion ranks over conversions to higher conversion ranks.</p>
   <p>With the proposed change to implicit conversions, preferring value-preserving conversions over lossy conversions comes for free, since overloads with lossy conversions won’t be viable candidates (except when both types are standard floating-point types).</p>
   <p>Preferring a conversion to a smaller type over a conversion to a larger type comes from the desire for a function call to be well-formed rather than ambiguous when there are multiple value-preserving conversions available.</p>
<pre class="highlight"><code class="highlight"><c- b><c- b>void</c-></c-> <c- nf><c- nf>f</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>float32_t</c-></c-><c- p><c- p>);</c-></c->
<c- b><c- b>void</c-></c-> <c- nf><c- nf>f</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>float64_t</c-></c-><c- p><c- p>);</c-></c->

<c- n><c- n>f</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>float16_t</c-></c-><c- p><c- p>(</c-></c-><c- mf><c- mf>1.0</c-></c-><c- p><c- p>));</c-></c-> <c- c1><c- c1>// calls std::float32_t, due to smaller conversion rank</c-></c->
<c- n><c- n>f</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>float</c-></c-><c- p><c- p>(</c-></c-><c- mf><c- mf>2.0</c-></c-><c- p><c- p>));</c-></c->          <c- c1><c- c1>// calls std::float32_t, due to smaller conversion rank</c-></c->
<c- n><c- n>f</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>double</c-></c-><c- p><c- p>(</c-></c-><c- mf><c- mf>3.0</c-></c-><c- p><c- p>));</c-></c->         <c- c1><c- c1>// calls std::float64_t, only viable candidate</c-></c->
</code></pre>
   <p>The behavior of preferring smaller-distance conversions over longer-distance conversions is not a new idea.  It was proposed for integer types in 2012 in <a data-link-type="biblio" href="#biblio-n3387">[N3387]</a>.  It was proposed for user-defined types in <a data-link-type="biblio" href="#biblio-p1818">[P1818]</a>.</p>
   <h5 class="heading settled" data-level="5.8.1.2" id="overload-no-change"><span class="secno">5.8.1.2. </span><span class="content">No change</span><a class="self-link" href="#overload-no-change"></a></h5>
   <p>The other alternative is to not change the overload resolution rules at all.  There would be no disambiguation between standard conversions, so any call with multiple viable function overloads with no exact match would be ambiguous.</p>
<pre class="highlight"><code class="highlight"><c- b><c- b>void</c-></c-> <c- nf><c- nf>f</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>float32_t</c-></c-><c- p><c- p>);</c-></c->
<c- b><c- b>void</c-></c-> <c- nf><c- nf>f</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>float64_t</c-></c-><c- p><c- p>);</c-></c->

<c- n><c- n>f</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>float16_t</c-></c-><c- p><c- p>(</c-></c-><c- mf><c- mf>1.0</c-></c-><c- p><c- p>));</c-></c-> <c- c1><c- c1>// ambiguous</c-></c->
<c- n><c- n>f</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>float</c-></c-><c- p><c- p>(</c-></c-><c- mf><c- mf>2.0</c-></c-><c- p><c- p>));</c-></c->          <c- c1><c- c1>// ambiguous</c-></c->
<c- n><c- n>f</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>double</c-></c-><c- p><c- p>(</c-></c-><c- mf><c- mf>3.0</c-></c-><c- p><c- p>));</c-></c->         <c- c1><c- c1>// calls std::float64_t, only viable candidate</c-></c->
</code></pre>
   <h4 class="heading settled" data-level="5.8.2" id="overload-comparison"><span class="secno">5.8.2. </span><span class="content">Comparisons</span><a class="self-link" href="#overload-comparison"></a></h4>
   <p>The following table shows how various function calls would be resolved under the overload resolution schemes discussed in this section.  "Ambiguous" means the call is ill-formed because there are multiple viable functions but none is preferred over the others.  "No match" means the call is ill-formed because none of the functions are viable.</p>
   <p>Assume that <code class="highlight"><c- b>float</c-></code> and <code class="highlight"><c- b>double</c-></code> are 32-bit and 64-bit IEEE floating-point respectively, which is true on most major implementations.  Assume that <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> is X87 80-bit, which is true for most Linux x86 compilers.  The types in <code class="highlight"><c- n>std</c-><c- o>::</c-></code> are the type aliases described in <a href="#alias">§ 7 Type aliases</a>.</p>
   <p>Assume the following variable declarations:</p>
<pre class="highlight"><c- n>std</c-><c- o>::</c-><c- n>bfloat16_t</c-> <c- n>bf_v</c-><c- p>;</c->
<c- n>std</c-><c- o>::</c-><c- n>float16_t</c->  <c- n>f16_v</c-><c- p>;</c->
<c- n>std</c-><c- o>::</c-><c- n>float32_t</c->  <c- n>f32_v</c-><c- p>;</c->
<c- n>std</c-><c- o>::</c-><c- n>float64_t</c->  <c- n>f64_v</c-><c- p>;</c->
<c- n>std</c-><c- o>::</c-><c- n>float128_t</c-> <c- n>f128_v</c-><c- p>;</c->
<c- b>float</c->           <c- n>float_v</c-><c- p>;</c->
<c- b>double</c->          <c- n>double_v</c-><c- p>;</c->
<c- b>long</c-> <c- b>double</c->     <c- n>ld_v</c-><c- p>;</c->
</pre>
   <p>Assume the following function declarations:</p>
<pre class="highlight"><c- b>void</c-> <c- nf>a</c-><c- p>(</c-><c- b>float</c-><c- p>);</c->
<c- b>void</c-> <c- nf>a</c-><c- p>(</c-><c- b>double</c-><c- p>);</c->
<c- b>void</c-> <c- nf>a</c-><c- p>(</c-><c- b>long</c-> <c- b>double</c-><c- p>);</c->

<c- b>void</c-> <c- nf>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float32_t</c-><c- p>);</c->
<c- b>void</c-> <c- nf>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-><c- p>);</c->
<c- b>void</c-> <c- nf>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float128_t</c-><c- p>);</c->
</pre>
   <table>
    <tbody>
     <tr>
      <th>Function call
      <th>Prefer smallest safe conversion (formerly proposed)
      <th>Prefer same conversion rank (currently proposed)
      <th>No preference (existing behavior)
     <tr>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- n>bf_v</c-><c- p>);</c-></code>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- b>float</c-><c- p>)</c-></code>
      <td>ambiguous
      <td>ambiguous
     <tr>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- n>f16_v</c-><c- p>);</c-></code>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- b>float</c-><c- p>)</c-></code>
      <td>ambiguous
      <td>ambiguous
     <tr>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- n>f32_v</c-><c- p>);</c-></code>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- b>float</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- b>float</c-><c- p>)</c-></code>
      <td>ambiguous
     <tr>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- n>f64_v</c-><c- p>);</c-></code>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- b>double</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- b>double</c-><c- p>)</c-></code>
      <td>ambiguous
     <tr>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- n>f128_v</c-><c- p>);</c-></code>
      <td>no match
      <td>no match
      <td>no match
     <tr>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- n>float_v</c-><c- p>);</c-></code>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- b>float</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- b>float</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- b>float</c-><c- p>)</c-></code>
     <tr>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- n>double_v</c-><c- p>);</c-></code>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- b>double</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- b>double</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- b>double</c-><c- p>)</c-></code>
     <tr>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- n>ld_v</c-><c- p>);</c-></code>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- b>long</c-> <c- b>double</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- b>long</c-> <c- b>double</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>a</c-><c- p>(</c-><c- b>long</c-> <c- b>double</c-><c- p>)</c-></code>
     <tr>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>bf_v</c-><c- p>);</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float32_t</c-><c- p>)</c-></code>
      <td>ambiguous
      <td>ambiguous
     <tr>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>f16_v</c-><c- p>);</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float32_t</c-><c- p>)</c-></code>
      <td>ambiguous
      <td>ambiguous
     <tr>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>f32_v</c-><c- p>);</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float32_t</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float32_t</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float32_t</c-><c- p>)</c-></code>
     <tr>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>f64_v</c-><c- p>);</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-><c- p>)</c-></code>
     <tr>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>f128_v</c-><c- p>);</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float128_t</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float128_t</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float128_t</c-><c- p>)</c-></code>
     <tr>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>float_v</c-><c- p>);</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float32_t</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float32_t</c-><c- p>)</c-></code>
      <td>ambiguous
     <tr>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>double_v</c-><c- p>);</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-><c- p>)</c-></code>
      <td>ambiguous
     <tr>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>ld_v</c-><c- p>);</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float128_t</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float128_t</c-><c- p>)</c-></code>
      <td><code class="highlight"><c- n>b</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float128_t</c-><c- p>)</c-></code>
   </table>
   <h3 class="heading settled" data-level="5.9" id="pointer"><span class="secno">5.9. </span><span class="content">Pointer conversions</span><a class="self-link" href="#pointer"></a></h3>
   <p>The proposal of allowing implicit conversions between pointers to two different floating-point types that have the same representation was voted down by EWG in Prague, so it has been withdrawn from this proposal.  Allowing the implicit pointer conversions would have eased the transition from using the standard floating-point types to the new named floating-point types.  But it complicated the language in a non-obvious way, and the group decided that the benefit was not worth the cost.</p>
   <h3 class="heading settled" data-level="5.10" id="core-test-macro"><span class="secno">5.10. </span><span class="content">Feature test macro</span><a class="self-link" href="#core-test-macro"></a></h3>
   <p class="issue" id="issue-6daed810"><a class="self-link" href="#issue-6daed810"></a> Should there be a feature test macro to indicate that the implementation supports at least one extended floating-point type?</p>
   <p>Implementations could support extended floating-point types without supporting any of the aliases for well-known layouts.  It might be useful to have a feature test macro that indicates support for extended floating-point types listed in 15.11 [<strong>cpp.predefined</strong>].  But it would likely have to be one of the conditionally-defined macros, and not listed in Table 17, since a conforming compiler might choose to not define any extended floating-point types.  If the macro is defined, it would not indicate which extended floating-point types are supported, only that there exists at least one extended floating-point type in the implementation.  The authors believe that such a feature test macro would not be useful, but would like SG10 to confirm that decision.</p>
   <h2 class="heading settled" data-level="6" id="library"><span class="secno">6. </span><span class="content">Library changes</span><a class="self-link" href="#library"></a></h2>
   <p>Making extended floating-point types easy to use does not require introducing any new names to the standard library.  But it does require adding new overloads or new template specializations in several places.  Some of the extended floating-point types will have standard names.  Those new names are covered in <a href="#alias">§ 7 Type aliases</a>.</p>
   <p>I/O of extended floating-point types can be done via I/O streams (with some limitations), <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>format</c-></code>, or <code class="highlight"><c- n>to_chars</c-></code>/<code class="highlight"><c- n>from_chars</c-></code>.  Changes are proposed to <code class="highlight"><c- o>&lt;</c-><c- n>ostream</c-><c- o>></c-></code>, <code class="highlight"><c- o>&lt;</c-><c- n>istream</c-><c- o>></c-></code>, and <code class="highlight"><c- o>&lt;</c-><c- n>charconv</c-><c- o>></c-></code> to support this.  No changes are necessary to <code class="highlight"><c- o>&lt;</c-><c- n>format</c-><c- o>></c-></code> because it already refers to all <em>arithmetic types</em>.</p>
   <p>Implementations will have to change <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>numeric_limits</c-></code> and <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>is_floating_point</c-></code> to give correct answers for extended floating-point types.  The existing wording in the standard already covers that (by referring to all <em>floating-point types</em> without listing them explicitly), so no wording changes are needed.</p>
   <p>Most of the standard functions that operate on floating-point types need wording changes to add overloads or template specializations for the extended floating-point types.  These classes and functions are in <code class="highlight"><c- o>&lt;</c-><c- n>cmath</c-><c- o>></c-></code>, <code class="highlight"><c- o>&lt;</c-><c- n>complex</c-><c- o>></c-></code>, and <code class="highlight"><c- o>&lt;</c-><c- n>atomic</c-><c- o>></c-></code>.</p>
   <p>No changes are proposed to the following parts of the standard library:</p>
   <ul>
    <li data-md>
     <p><code class="highlight"><c- o>&lt;</c-><c- n>cfloat</c-><c- o>></c-></code>: The header <code class="highlight"><c- o>&lt;</c-><c- n>cfloat</c-><c- o>></c-></code> provides macros describing some of the properties of the standard floating-point types.  The use of macros does not extend very well to extended floating-point types with implementation-specific names.  Users should use <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>numeric_limits</c-></code> rather than macros from <code class="highlight"><c- o>&lt;</c-><c- n>cfloat</c-><c- o>></c-></code> to query the properties of extended floating-point types.</p>
    <li data-md>
     <p>The <code class="highlight"><c- n>printf</c-></code> and <code class="highlight"><c- n>scanf</c-></code> families of functions: There is no practical way to add specifiers for implementation-specific types with implementation-specific names.  C23 will not provide <code class="highlight"><c- n>printf</c-></code> and <code class="highlight"><c- n>scanf</c-></code> support for its non-standard floating-point types, so there is no C standard library example to borrow from or build on for this proposal.</p>
    <li data-md>
     <p>The <code class="highlight"><c- n>strtod</c-></code> and <code class="highlight"><c- n>stod</c-></code> families of functions: With different names for each floating-point type (which for <code class="highlight"><c- n>strtod</c-></code> was inherited from C), that scheme doesn’t work well for extended floating-point types.</p>
    <li data-md>
     <p>The <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>to_string</c-></code> family of functions:  They are defined in terms of <code class="highlight"><c- n>snprintf</c-></code>, which will not support extended floating-point types.</p>
    <li data-md>
     <p><code class="highlight"><c- o>&lt;</c-><c- n>random</c-><c- o>></c-></code>:  [rand.req] states that certain template arguments have to be <code class="highlight"><c- b>float</c-></code>, <code class="highlight"><c- b>double</c-></code>, or <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>.  The wording could be changed to allow any floating-point type, but <code class="highlight"><c- o>&lt;</c-><c- n>random</c-><c- o>></c-></code> does not support extended integral types, so we are not proposing that it be required to support extended floating-point types either.</p>
   </ul>
   <p>WG14 is adding optional support for additional floating-point types in an annex to C23.  (See <a href="#c-compat">§ 4 C Compatibility</a>.)  C++ users will eventually see support for some of C++'s extended floating-point types through macros defined in <code class="highlight"><c- o>&lt;</c-><c- n>cfloat</c-><c- o>></c-></code> and conversion functions in <code class="highlight"><c- o>&lt;</c-><c- n>cstdlib</c-><c- o>></c-></code>.  This proposal is not suggesting identical changes ahead of C23 in these areas.  The changes will come to C++ when C++ is rebased on top of C23’s standard library.</p>
   <h3 class="heading settled" data-level="6.1" id="new-names"><span class="secno">6.1. </span><span class="content">Possible new names</span><a class="self-link" href="#new-names"></a></h3>
   <p>While no new names need to be added to the standard library for extended floating-point types to be useful, some new things that could be useful were considered.  The authors decided that they are not useful enough to be worth adding to the standard library.  They can easily be added later if it turns out that we were wrong about their usefulness.</p>
   <h4 class="heading settled" data-level="6.1.1" id="new-names-standard"><span class="secno">6.1.1. </span><span class="content">Standard/extended floating-point traits</span><a class="self-link" href="#new-names-standard"></a></h4>
   <p><code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>is_floating_point_v</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code> is true for both standard and extended floating-point types.  It might be nice if there were traits for <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>is_standard_floating_point</c-></code> and/or <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>is_extended_floating_point</c-></code>.  But it is not clear why user code would want to distinguish between standard types and extended types.  If code needs to do that, a user-defined trait for detecting standard floating-point types can be written easily enough with something like <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>is_same_v</c-><c- o>&lt;</c-><c- n>T</c-><c- p>,</c-> <c- b>float</c-><c- o>></c-> <c- o>||</c-> <c- n>std</c-><c- o>::</c-><c- n>is_same_v</c-><c- o>&lt;</c-><c- n>T</c-><c- p>,</c-> <c- b>double</c-><c- o>></c-> <c- o>||</c-> <c- n>std</c-><c- o>::</c-><c- n>is_same_v</c-><c- o>&lt;</c-><c- n>T</c-><c- p>,</c-> <c- b>long</c-> <c- b>double</c-><c- o>></c-></code>.</p>
   <h4 class="heading settled" data-level="6.1.2" id="new-names-conv"><span class="secno">6.1.2. </span><span class="content">Conversion rank trait</span><a class="self-link" href="#new-names-conv"></a></h4>
   <p>A type trait that compares the conversion rank of two floating-point types would be useful in situations where generic code needs to know if conversions between the types are safe.  See the <a href="#complex-wording">constructors</a> for <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>complex</c-></code> as an example of this.</p>
   <p>But we are not proposing that such a trait be added.  The API for this trait is not obvious, because there are five possible results when comparing conversion ranks: unordered, less than, greater than, equal with a lesser subrank, and equal with a greater subrank.  We think that many potential uses of the trait could use <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>is_convertible</c-></code> instead, or even better yet <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>is_convertible_without_narrowing</c-></code> as proposed in <a data-link-type="biblio" href="#biblio-p0870">[P0870]</a>.</p>
   <h3 class="heading settled" data-level="6.2" id="charconv"><span class="secno">6.2. </span><span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>charconv</c-><c- o>></c-></code></span><a class="self-link" href="#charconv"></a></h3>
   <p>Add overloads for all extended floating-point types for the functions <code class="highlight"><c- n>to_chars</c-></code> and <code class="highlight"><c- n>from_chars</c-></code>.</p>
   <p>Given how much effort it took to implement <code class="highlight"><c- n>to_chars</c-></code> and <code class="highlight"><c- n>from_chars</c-></code> for the existing floating-point types, there is some concern that this requirement will be an excessive burden on implementors.  After some research and discussions with STL, we feel that the implementation burden will be manageable.</p>
   <p>There are several existing algorithms that can be used to implement <code class="highlight"><c- n>to_chars</c-></code>, such as Ryu and Dragonbox.  The <a data-link-type="biblio" href="#biblio-ryu">[Ryu]</a> GitHub repository has a reference implementation of the algorithm which covers all the floating point types discussed in <a href="#alias">§ 7 Type aliases</a>.  See <code class="highlight"><c- n>ryu_generic_128</c-><c- p>.</c-><c- n>h</c-></code> for reference.</p>
   <p>The <a data-link-type="biblio" href="#biblio-eisel-lemire">[Eisel-Lemire]</a> algorithm can be used to implement <code class="highlight"><c- n>from_chars</c-></code>.  There is no reference implementation for 128-bit floating-point numbers yet, but the underlying algorithm has no fundamental limitation that would prevent its usage for large floating-point types.</p>
   <p><i>Wording: <a href="#charconv-wording">§ 8.2.2 &lt;charconv></a></i></p>
   <h3 class="heading settled" data-level="6.3" id="format"><span class="secno">6.3. </span><span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>format</c-><c- o>></c-></code></span><a class="self-link" href="#format"></a></h3>
   <p>No wording changes are necessary for <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>format</c-></code> to support extended floating-point types. <a href="http://eel.is/c++draft/format.formatter.spec#2.3">[format.formatter.spec]/p2.3</a> already requires that there be a specialization of <code class="highlight"><c- k>struct</c-> <c- nc>formatter</c-></code> for each arithmetic type, which covers the extended floating-point types.</p>
   <p><a href="http://eel.is/c++draft/format.string.std#tab:format.type.float">[tab:format.type.float]</a> in [format.string.std]/p22 specifies the behavior of floating-point types in terms of <code class="highlight"><c- n>to_chars</c-></code>, which will support extended floating-point types.</p>
   <h3 class="heading settled" data-level="6.4" id="iostream"><span class="secno">6.4. </span><span class="content">I/O Streams</span><a class="self-link" href="#iostream"></a></h3>
   <p>Add support to <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>ostream</c-></code> and <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>istream</c-></code>, via overloaded <code class="highlight"><c- k>operator</c-><c- o>&lt;&lt;</c-></code> and <code class="highlight"><c- k>operator</c-><c- o>>></c-></code>, for extended floating-point types whose conversion ranks are less than or equal to <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>.  Types whose conversion ranks are greater than or unordered with <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> will not be handled by I/O streams.</p>
   <p>The streaming operators use the virtual functions <code class="highlight"><c- n>num_put</c-><c- o>&lt;>::</c-><c- n>do_put</c-></code> and <code class="highlight"><c- n>num_get</c-><c- o>&lt;>::</c-><c- n>do_get</c-></code> for output and input of arithmetic types.  To fully and properly support extended floating-point types, new virtual functions would need to be added.  That would be an ABI break.  While an ABI break is not out of the question, it would have strong opposition.  This proposal is not worth the effort that would be necessary to get an ABI break through the committee.</p>
   <p>Therefore, extended floating-point types are supported as well as possible without changing <code class="highlight"><c- n>num_put</c-></code> or <code class="highlight"><c- n>num_get</c-></code>.  For any extended floating-point type that is no bigger than <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>, the extended floating-point value is converted to <code class="highlight"><c- b>float</c-></code>, <code class="highlight"><c- b>double</c-></code>, or <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>, as appropriate, and one of the existing <code class="highlight"><c- n>do_put</c-></code> or <code class="highlight"><c- n>do_get</c-></code> functions is called.  For types that are larger than <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>, there are no existing <code class="highlight"><c- n>do_put</c-></code> or <code class="highlight"><c- n>do_get</c-></code> functions that have the necessary range and precision.  It is proposed that <code class="highlight"><c- k>operator</c-><c- o>&lt;&lt;</c-></code> and <code class="highlight"><c- k>operator</c-><c- o>>></c-></code> for these types be defined as deleted.</p>
   <p><i>Wording: <a href="#iostream-wording">§ 8.2.3 I/O Streams</a></i></p>
   <h3 class="heading settled" data-level="6.5" id="cmath"><span class="secno">6.5. </span><span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>cmath</c-><c- o>></c-></code></span><a class="self-link" href="#cmath"></a></h3>
   <p>Add overloads for extended floating-point types to the functions in <code class="highlight"><c- o>&lt;</c-><c- n>cmath</c-><c- o>></c-></code>.  It is expected that this will be the most used part of the library changes.</p>
   <p>Trivial implementations of the math functions for extended floating-point types that are no bigger than <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> can be done by casting the arguments to a standard floating-point that is at least as big as the extended floating-point type, doing the calculations with the standard floating-point type, then casting the result back down to the extended floating-point type.</p>
   <p>The GCC <a data-link-type="biblio" href="#biblio-libquadmath">[libquadmath]</a> library contains a reference implementation for <code class="highlight"><c- o>&lt;</c-><c- n>math</c-><c- p>.</c-><c- n>h</c-><c- o>></c-></code> functions with IEEE 128-bit floating-point.  However, we do not know of any accuracy analyses for mathematical special functions described in section <strong>[sf.cmath]</strong> with 128-bit floating-point type arguments.</p>
   <p><i>Wording: <a href="#cmath-wording">§ 8.2.4 &lt;cmath></a></i></p>
   <h3 class="heading settled" data-level="6.6" id="complex"><span class="secno">6.6. </span><span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>complex</c-><c- o>></c-></code></span><a class="self-link" href="#complex"></a></h3>
   <p>Make <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>complex</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code> be well-defined when <code class="highlight"><c- n>T</c-></code> is an extended floating-point type.  The explicit specializations of <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>complex</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code> are removed.  The only differences between the explicit specializations was the explicit-ness of the constructors that take a complex number of a different type.  This behavior is incorporated into the main class template through <code class="highlight"><c- k>explicit</c-><c- p>(</c-><c- b>bool</c-><c- p>)</c-></code>.</p>
   <p>No literal suffixes are defined for complex numbers of extended floating-point types.  Subclause [complex.literals] is unchanged.</p>
   <p class="issue" id="issue-c91d4ff8"><a class="self-link" href="#issue-c91d4ff8"></a> Should literal suffixes be defined for complex numbers of extended floating-point types with standard names, similar to the non-complex <a href="#literals">suffixes</a>?</p>
   <p><i>Wording: <a href="#complex-wording">§ 8.2.5 &lt;complex></a></i></p>
   <h3 class="heading settled" data-level="6.7" id="atomic"><span class="secno">6.7. </span><span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>atomic</c-><c- o>></c-></code></span><a class="self-link" href="#atomic"></a></h3>
   <p>The specification for the integral specializations of <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>atomic</c-></code> states in [atomics.types.int]: "There are specializations of the <code class="highlight"><c- n>atomic</c-></code> class template for the integral types [<em>all the standard integral types</em>], and any other types needed by the typedefs in the header <code class="highlight"><c- o>&lt;</c-><c- n>cstdint</c-><c- o>></c-></code>."</p>
   <p>A similar approach is taken for floating-point types. <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>atomic</c-></code> has specializations for all the standard floating-point types and for any extended floating-point types that are used for the aliases (<a href="#alias">§ 7 Type aliases</a>) defined in the <code class="highlight"><c- o>&lt;</c-><c- n>stdfloat</c-><c- o>></c-></code> header (<a href="#alias-header">§ 7.1 Header name</a>).</p>
   <p><i>Wording: <a href="#atomic-wording">§ 8.2.6 &lt;atomic></a></i></p>
   <h3 class="heading settled" data-level="6.8" id="lib-test-macro"><span class="secno">6.8. </span><span class="content">Feature test macro</span><a class="self-link" href="#lib-test-macro"></a></h3>
   <p>No feature test macro is being proposed for the library changes in this section.  These library changes would be covered by the core language <a href="#core-test-macro">feature test macro</a>, if there is one.</p>
   <h2 class="heading settled" data-level="7" id="alias"><span class="secno">7. </span><span class="content">Type aliases</span><a class="self-link" href="#alias"></a></h2>
   <p>This paper introduces type aliases for several fixed-layout floating-point types.  Each alias will be defined only if a type with that layout is supported by the implementation, similar to the <code class="highlight"><c- n>intN_t</c-></code> and <code class="highlight"><c- n>uintN_t</c-></code> aliases.</p>
   <p><i>Wording: <a href="#stdfloat-wording">§ 8.2.1 &lt;stdfloat></a></i></p>
   <h3 class="heading settled" data-level="7.1" id="alias-header"><span class="secno">7.1. </span><span class="content">Header name</span><a class="self-link" href="#alias-header"></a></h3>
   <p>The type aliases proposed here do not fit neatly into any existing header.  We are proposing that the type aliases be added to a new header <code class="highlight"><c- o>&lt;</c-><c- n>stdfloat</c-><c- o>></c-></code>.  We are not thrilled with that choice, so we are open to other suggestions.  An LEWG mailing list discussion of the header name did not generate much discussion or any clear favorite.</p>
   <p>An argument can be made to define the type aliases in <code class="highlight"><c- o>&lt;</c-><c- n>cfloat</c-><c- o>></c-></code>, since the macros that expose the characteristics of floating-point types, including the C23 <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em></code> types, are defined in <code class="highlight"><c- o>&lt;</c-><c- b>float</c-><c- p>.</c-><c- n>h</c-><c- o>></c-></code>.  There is some precedent for C++ adding new stuff to the C++ versions of C headers, but it is not commonly done and is not the preferred solution.</p>
   <h3 class="heading settled" data-level="7.2" id="alias-formats"><span class="secno">7.2. </span><span class="content">Supported formats</span><a class="self-link" href="#alias-formats"></a></h3>
   <p>We propose aliases for the following layouts:</p>
   <ul>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-ieee-754-2008">[IEEE-754-2008]</a> <code class="highlight"><c- n>binary16</c-></code> - IEEE 16-bit.</p>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-ieee-754-2008">[IEEE-754-2008]</a> <code class="highlight"><c- n>binary32</c-></code> - IEEE 32-bit.</p>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-ieee-754-2008">[IEEE-754-2008]</a> <code class="highlight"><c- n>binary64</c-></code> - IEEE 64-bit.</p>
    <li data-md>
     <p><a data-link-type="biblio" href="#biblio-ieee-754-2008">[IEEE-754-2008]</a> <code class="highlight"><c- n>binary128</c-></code> - IEEE 128-bit.</p>
    <li data-md>
     <p><code class="highlight"><c- n>bfloat16</c-></code>, which is <code class="highlight"><c- n>binary32</c-></code> with 16 bits of precision truncated; see <a data-link-type="biblio" href="#biblio-bfloat16">[bfloat16]</a>.</p>
   </ul>
   <p><code class="highlight"><c- n>binary32</c-></code> and <code class="highlight"><c- n>binary64</c-></code> are the most widely used floating-point types, and are the formats that <code class="highlight"><c- b>float</c-></code> and <code class="highlight"><c- b>double</c-></code> have in most implementations. <code class="highlight"><c- n>binary16</c-></code> is becoming more widely used; see this paper’s motivation for details. <code class="highlight"><c- n>binary128</c-></code> has hardware support in IBM POWER P9 chips. <code class="highlight"><c- n>bfloat16</c-></code> is used in Google’s TPUs and in TensorFlow and has hardware support in NVIDIA’s latest GPUs.</p>
   <p>The most widely used format that is not in this list is X87 80-bit.  Even though there is hardware support for this format in all current x86 chips, it is used most often because it is the largest type available, not because users specifically want that format.</p>
   <h3 class="heading settled" data-level="7.3" id="alias-alias"><span class="secno">7.3. </span><span class="content">Aliasing standard types</span><a class="self-link" href="#alias-alias"></a></h3>
   <p>This has turned out to be the most contentious issue with the type aliases, with strong opinions on both sides.  In Cologne, SG6 (Numerics) and LEWGI voted in favor of allowing aliasing of standard types, while EWGI was strongly against the idea.  After the Cologne meeting, the authors decided that prohibiting aliases of standard types was the better choice.  EWG discussed the issue in Prague and there was very strong consensus for the authors' position.  "The new floatX_t types aren’t aliases for float / double / long double, they are independent types." 23-13-0-2-0</p>
   <p>The header <code class="highlight"><c- o>&lt;</c-><c- n>cstdint</c-><c- o>></c-></code> defines integer type aliases for certain integer types, such as <code class="highlight"><c- n>std</c-><c- o>::</c-><c- b>int32_t</c-></code> and <code class="highlight"><c- n>std</c-><c- o>::</c-><c- b>int64_t</c-></code>.  These are similar in many ways to the aliases proposed here.  The types in <code class="highlight"><c- o>&lt;</c-><c- n>cstdint</c-><c- o>></c-></code> are allowed to alias standard integer types.  That has resulted in compilation errors when users try to create an overload set with both standard types and fixed-layout aliases, such as:</p>
<pre class="highlight"><code class="highlight"><c- b><c- b>int</c-></c-> <c- nf><c- nf>bit_count</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>int</c-></c-> <c- n><c- n>x</c-></c-><c- p><c- p>)</c-></c-> <c- p><c- p>{</c-></c-> <c- d><c- d>/* ... */</c-></c-> <c- p><c- p>}</c-></c->
<c- b><c- b>int</c-></c-> <c- nf><c- nf>bit_count</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- b><c- b>int32_t</c-></c-> <c- n><c- n>x</c-></c-><c- p><c- p>)</c-></c-> <c- p><c- p>{</c-></c-> <c- d><c- d>/* ... */</c-></c-> <c- p><c- p>}</c-></c->
</code></pre>
   <p>If aliasing of standard types is allowed for the floating-point type aliases, then similar compilation errors will likely result:</p>
<pre class="highlight"><code class="highlight"><c- b><c- b>int</c-></c-> <c- nf><c- nf>get_exponent</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>double</c-></c-> <c- n><c- n>x</c-></c-><c- p><c- p>)</c-></c-> <c- p><c- p>{</c-></c-> <c- d><c- d>/* ... */</c-></c-> <c- p><c- p>}</c-></c->
<c- b><c- b>int</c-></c-> <c- nf><c- nf>get_exponent</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>float64_t</c-></c-> <c- n><c- n>x</c-></c-><c- p><c- p>)</c-></c-> <c- p><c- p>{</c-></c-> <c- d><c- d>/* ... */</c-></c-> <c- p><c- p>}</c-></c->
</code></pre>
   <p>This is the strongest argument against allowing aliasing of standard types.  People who don’t find this argument persuasive point out that users should not create overload sets with both standard types and fixed-layout type aliases.  An overload set should contain just the standard floating-point types or just the fixed-layout types, but not both.  The example above that fails to compile is considered poor design and should not be encouraged.</p>
   <p>(The arguments about overload sets apply equally to explicit template specializations.)</p>
   <p>Not allowing the aliasing of standard types imposes an implementation burden.  If aliasing were allowed, then implementations that don’t define any extended floating-point types could define some of the aliases with a little bit of library code that boils down to something like:</p>
<pre class="highlight"><code class="highlight"><c- k><c- k>namespace</c-></c-> <c- n><c- n>std</c-></c-> <c- p><c- p>{</c-></c->
  <c- k><c- k>using</c-></c-> <c- n><c- n>float32_t</c-></c-> <c- o><c- o>=</c-></c-> <c- b><c- b>float</c-></c-><c- p><c- p>;</c-></c->
  <c- k><c- k>using</c-></c-> <c- n><c- n>float64_t</c-></c-> <c- o><c- o>=</c-></c-> <c- b><c- b>double</c-></c-><c- p><c- p>;</c-></c->
<c- p><c- p>}</c-></c->
</code></pre>
   <p>But when aliasing is not allowed, implementations have to support extended floating-point types in at least the compiler front end, which is not a trivial task.  There is also a burden on the name mangling ABI, which will have to define how to encode these extended floating-point types.</p>
   <p>The authors feel that the burden on users of allowing aliasing of standard types is greater than the burden on implementers of not allowing such aliasing.</p>
   <p>(This issue of aliasing of standard types is tightly bound to the overload resolution rules (<a href="#overload">§ 5.8 Overload resolution</a>) for extended floating-point types.  If the overload resolution rules are not changed, then having <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code> be an alias of an extended floating-point type rather than an alias of <code class="highlight"><c- b>double</c-></code> will cause the following code to not compile:</p>
<pre class="highlight"><code class="highlight"><c- b><c- b>void</c-></c-> <c- nf><c- nf>f</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>float32_t</c-></c-><c- p><c- p>);</c-></c->
<c- b><c- b>void</c-></c-> <c- nf><c- nf>f</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>float64_t</c-></c-><c- p><c- p>);</c-></c->
<c- b><c- b>void</c-></c-> <c- nf><c- nf>g</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>double</c-></c-> <c- n><c- n>x</c-></c-><c- p><c- p>)</c-></c-> <c- p><c- p>{</c-></c->
  <c- n><c- n>f</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>x</c-></c-><c- p><c- p>);</c-></c-> <c- c1><c- c1>// error - ambiguous call without overload resolution changes</c-></c->
<c- p><c- p>}</c-></c->
</code></pre>
   <p>If that code doesn’t compile, that would be a bigger burden on users than not being able to overload on both <code class="highlight"><c- b>double</c-></code> and <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code>.)</p>
   <h3 class="heading settled" data-level="7.4" id="layout-vs-behavior"><span class="secno">7.4. </span><span class="content">Layout vs. behavior</span><a class="self-link" href="#layout-vs-behavior"></a></h3>
   <p>The IEEE-conforming type aliases have the specified IEEE layout and the required behavior.  For the four IEEE-conforming type aliases, <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>numeric_limits</c-><c- o>&lt;</c-><c- n>T</c-><c- o>>::</c-><c- n>is_iec559</c-></code> is true.</p>
   <h3 class="heading settled" data-level="7.5" id="test-macros"><span class="secno">7.5. </span><span class="content">Feature test macros</span><a class="self-link" href="#test-macros"></a></h3>
   <p>Since implementations may choose to support (or not) each of the fixed-layout aliases individually, there should be a separate test macro for detecting each of the type aliases.  The names of the test macros would be derived from the names of type alias names.  (The authors are not thrilled with introducing so many new test macros, but they have yet to come up with a better idea.)</p>
   <p class="issue" id="issue-50e4e46f"><a class="self-link" href="#issue-50e4e46f"></a> How should feature test macros be handled for this feature?</p>
   <p><i>Wording: <a href="#test-macros-wording">§ 8.2.7 Feature test macros</a></i></p>
   <h3 class="heading settled" data-level="7.6" id="names"><span class="secno">7.6. </span><span class="content">Names</span><a class="self-link" href="#names"></a></h3>
   <p>Earlier revisions of this proposal listed several different possible naming schemes without arguing for one in particular.  After an e-mail discussion of this topic on the LEWG mailing list in September 2021 resulted in a clear favorite among those who expressed an opinion, we are proposing the simplest and most straightforward of the proposed naming schemes, and the one already used by Boost.Math (though Boost does not put them in namespace <code class="highlight"><c- n>std</c-></code>):</p>
   <ul>
    <li data-md>
     <p><code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float16_t</c-></code></p>
    <li data-md>
     <p><code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float32_t</c-></code></p>
    <li data-md>
     <p><code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code></p>
    <li data-md>
     <p><code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float128_t</c-></code></p>
    <li data-md>
     <p><code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>bfloat16_t</c-></code></p>
   </ul>
   <p>People liked the simplicity of "float".  Even though "float" can refer to decimal floating-point or non-IEEE floating-point formats, for most programmers IEEE binary floating-point is the first thing that comes to mind with the word "float".</p>
   <p>Some of the other formats that were considered but were not adopted are <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>fp</c-><c- o>::</c-><c- n>binary</c-><em><c- n>N</c-></em><c- n>_t</c-></code>, <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>fp_binary</c-><em><c- n>N</c-></em><c- n>_t</c-></code>, <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>iec559</c-><c- o>::</c-><c- n>binary</c-><em><c- n>N</c-></em><c- n>_t</c-></code>, and <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>iec559_binary</c-><em><c- n>N</c-></em><c- n>_t</c-></code>.  While the use of "binary" may be more accurate at distinguishing binary floating-point from decimal floating-point, floating-point arithmetic is not the first thing that comes to most users mind when they read the word "binary".</p>
   <h4 class="heading settled" data-level="7.6.1" id="names-c"><span class="secno">7.6.1. </span><span class="content">C compatibility</span><a class="self-link" href="#names-c"></a></h4>
   <p>C23 defines <code class="highlight"><c- n>_Float16</c-></code>, <code class="highlight"><c- n>_Float32</c-></code>, <code class="highlight"><c- n>_Float64</c-></code>, and <code class="highlight"><c- n>_Float128</c-></code> as optional keywords naming the IEEE types. <a data-link-type="biblio" href="#biblio-wg14-n2601">[WG14-N2601]</a> This paper proposes type aliases in the <code class="highlight"><c- n>std</c-></code> namespace for those same types.  Since C++ likes to have all its library names in namespace <code class="highlight"><c- n>std</c-></code>, and C does not have namespace <code class="highlight"><c- n>std</c-></code> at all, it seems unavoidable that there will be some divergence in this area.  Code that is intended to be compiled only as C will use the <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em></code> names, while code that is intended to be compiled only as C++ will likely use the <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float</c-><em><c- n>N</c-></em><c- n>_t</c-></code> names.  It would be nice, however, if code that is intended to be compiled in both languages could use names that would work in both languages without having to resort to something like:</p>
<pre class="highlight"><c- cp>#ifdef __cplusplus</c->
  <c- cp>#include</c-> &lt;stdfloat>
  <c- k>using</c-> <c- n>my_fp16_t</c-> <c- o>=</c-> <c- n>std</c-><c- o>::</c-><c- n>float16_t</c-><c- p>;</c->
<c- cp>#else</c->
  <c- k>typedef</c-> <c- n>_Float16</c-> <c- n>my_fp16_t</c-><c- p>;</c->
<c- cp>#endif</c->
</pre>
   <p>C++ implementations could use the <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em></code> names as the names behind the <code class="highlight"><c- n>std</c-><c- o>::</c-></code> aliases, allowing the use of the <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em></code> names in both languages.  I expect that most C++ implementations that support extended floating-point types will do this even if it is not required.  We could in theory rely on the quality of implementations to get common names in both languages, but that is not a very satisfying approach.</p>
   <p>Another way to get common names is for the C++ standard to require C++ implementations to provide the <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em></code> names in addition to the <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float</c-><em><c- n>N</c-></em><c- n>_t</c-></code> names.  The <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em></code> names could be conditionally supported keywords in C++ like they are in C.  Or the <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em></code> names could be type aliases at global scope that are available when any floating-point-related header is included, such as <code class="highlight"><c- o>&lt;</c-><c- n>math</c-><c- p>.</c-><c- n>h</c-><c- o>></c-></code> or <code class="highlight"><c- o>&lt;</c-><c- b>float</c-><c- p>.</c-><c- n>h</c-><c- o>></c-></code>.  A discussion about this on the EWG and SG22 mailing lists didn’t have any consensus, but there was some support for making the <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em></code> names available in C++ in some way and some resistance to making them keywords.  A poll during an SG22 teleconference had weak consensus for making the C names available in C++, but there wasn’t discussion or a poll about how best to do that.</p>
   <p>We would like an LEWG poll about whether or not the <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em></code> names should be required to be available at global scope in C++.  And if so, whether they are always available (if that type is supported) or require including a header.  The authors are opposed to requiring that the <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em></code> names be made available in C++, but are still requesting the poll because consensus has not been reached yet on the issue.  Not requiring the names to be available is the safer choice, since the standard can safely be changed later to require them, but if they are in the standard it would be difficult to remove them.</p>
   <p>C23 will define the typedefs <code class="highlight"><c- n>float_t</c-></code>, <code class="highlight"><c- n>double_t</c-></code>, <code class="highlight"><c- n>long_double_t</c-></code>, and <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em><c- n>_t</c-></code>.  See X.11 in <a data-link-type="biblio" href="#biblio-wg14-n2601">[WG14-N2601]</a>. <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em><c- n>_t</c-></code> is not necessarily a typedef of <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em></code>; it might be an alias for a different floating-point type depending on the value of <code class="highlight"><c- n>FLT_EVAL_METHOD</c-></code>.  A concern has been raised that the <code class="highlight"><c- n>_Float</c-><em><c- n>N</c-></em><c- n>_t</c-></code> names in C may be confused with the <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float</c-><em><c- n>N</c-></em><c- n>_t</c-></code> names in C++; users might incorrectly assume that <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float32_t</c-></code> is the same type as <code class="highlight"><c- n>_Float32_t</c-></code>, when instead it is the same type as <code class="highlight"><c- n>_Float32</c-></code>.  The authors acknowledge this concern, but we feel it is not serious enough to justify changing the C++ names.  The consistency with the <code class="highlight"><c- n>_t</c-></code> suffix of many other C++ type aliases is more important than minimizing potential confusion with C type names.  This was polled during an SG22 teleconference, and changing <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float</c-><em><c- n>N</c-></em><c- n>_t</c-></code> to <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float</c-><em><c- n>N</c-></em></code> did not have consensus.</p>
   <h3 class="heading settled" data-level="7.7" id="literals"><span class="secno">7.7. </span><span class="content">Literal suffixes</span><a class="self-link" href="#literals"></a></h3>
   <p>C23 defines literal suffixes for IEEE interchange formats and extended formats, for both binary and decimal floating point.  The literal suffixes that correspond to type defined in this proposal are <code class="highlight"><c- n>f16</c-></code>, <code class="highlight"><c- n>f32</c-></code>, <code class="highlight"><c- n>f64</c-></code>, <code class="highlight"><c- n>f128</c-></code>, and their upper-case versions <code class="highlight"><c- n>F16</c-></code>, <code class="highlight"><c- n>F32</c-></code>, <code class="highlight"><c- n>F64</c-></code>, and <code class="highlight"><c- n>F128</c-></code>.</p>
   <p>We propose matching literal suffixes for C++: <code class="highlight"><c- n>f16</c-></code> for <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float16_t</c-></code>, <code class="highlight"><c- n>f32</c-></code> for <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float32_t</c-></code>, <code class="highlight"><c- n>f64</c-></code> for <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code>, and <code class="highlight"><c- n>f128</c-></code> for <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float128_t</c-></code>.  Plus an additional suffix, <code class="highlight"><c- n>bf16</c-></code> for <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>bfloat16_t</c-></code>, which is not covered by the C standard.</p>
   <p>In this proposal, the literal suffixes are a library feature, requiring an <code class="highlight"><c- cp>#include</c-></code> and a <code class="highlight"><c- k>using</c-> <c- k>namespace</c-></code> directive to use them.</p>
   <p>Some reviewers of this proposal have requested that the literal suffixes be a language feature, not a library feature, to increase compatibility with C.  The authors are opposed to this and prefer to keep the literal suffixes as a library feature.  If the literal suffixes start as a library feature, they can safely be changed later to be built-in to the language.  But if they start as a language feature, it would be very difficult to later change them to be a library feature.  We would like an LEWG poll on this topic.  If the poll results in the literal suffixes being built-in to the language, then both the lower-case and upper-case forms, e.g. <code class="highlight"><c- n>f64</c-></code> and <code class="highlight"><c- n>F64</c-></code>, will be supported, just like for all other built-in suffixes.  If the literal suffixes remain a library feature, then only the lower-case version will be supported, just like for all other library-based literal suffixes.</p>
   <h2 class="heading settled" data-level="8" id="wording"><span class="secno">8. </span><span class="content">Wording</span><a class="self-link" href="#wording"></a></h2>
   <p>All wording changes are relative to C++20.</p>
   <h3 class="heading settled" data-level="8.1" id="wording-core"><span class="secno">8.1. </span><span class="content">Core</span><a class="self-link" href="#wording-core"></a></h3>
   <h4 class="heading settled" data-level="8.1.1" id="extended-wording"><span class="secno">8.1.1. </span><span class="content">Extended floating-point types</span><a class="self-link" href="#extended-wording"></a></h4>
   <p><i>Design: <a href="#extended">§ 5.2 Extended floating-point types</a></i></p>
   <p>Modify 6.8.1 "Fundamental types" [<strong>basic.fundamental</strong>] paragraph 12:</p>
   <blockquote>
     There are three <i><ins>standard </ins>floating-point types</i>: <code class="highlight"><c- b>float</c-></code>, <code class="highlight"><c- b>double</c-></code>, and <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>. The type <code class="highlight"><c- b>double</c-></code> provides at least as much precision as <code class="highlight"><c- b>float</c-></code>, and the type <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> provides at least as much precision as <code class="highlight"><c- b>double</c-></code>. The set of values of the type <code class="highlight"><c- b>float</c-></code> is a subset of the set of values of the type <code class="highlight"><c- b>double</c-></code>; the set of values of the type <code class="highlight"><c- b>double</c-></code> is a subset of the set of values of the type <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>. 
    <ins>There may also be implementation-defined <em>extended floating-point types</em>. The standard and extended floating-point types are collectively called <em>floating-point types</em>.</ins>
     The value representation of floating-point types is implementation-defined. [...] 
   </blockquote>
   <h4 class="heading settled" data-level="8.1.2" id="rank-wording"><span class="secno">8.1.2. </span><span class="content">Conversion rank</span><a class="self-link" href="#rank-wording"></a></h4>
   <p><i>Design: <a href="#rank">§ 5.3 Conversion rank</a></i></p>
   <p>
    Change the title of section 6.8.4 [<strong>conv.rank</strong>] from "
    <del>Integer conversion rank</del>
    " to "
    <ins>Conversion ranks</ins>
    ", but leave the stable name unchanged.  Insert new paragraphs at the end of the subclause:
   </p>
   <blockquote class="ins">
     Every floating-point type has a <em>floating-point conversion rank</em> defined as follows: 
    <ul>
     <li data-md>
      <p>The rank of a floating point type <code class="highlight"><c- n>T</c-></code> is greater than the rank of any floating-point type whose set of values is a proper subset of the set of values of <code class="highlight"><c- n>T</c-></code>.</p>
     <li data-md>
      <p>The rank of <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> is greater than the rank of <code class="highlight"><c- b>double</c-></code>, which is greater than the rank of <code class="highlight"><c- b>float</c-></code>.</p>
     <li data-md>
      <p>Two extended floating-point types with the same set of values have equal ranks.</p>
     <li data-md>
      <p>An extended floating-point type with the same set of values as exactly one standard floating-point type has a rank equal to the rank of the standard floating-point type.</p>
     <li data-md>
      <p>An extended floating-point type with the same set of values as more than one standard floating-point type has a rank equal to the rank of <code class="highlight"><c- b>double</c-></code>.</p>
    </ul>
    <p>[ <em>Note</em>: The conversion ranks of floating-point types <code class="highlight"><c- n>T1</c-></code> and <code class="highlight"><c- n>T2</c-></code> are unordered if the set of values of <code class="highlight"><c- n>T1</c-></code> is neither a subset nor a superset of the set of values of <code class="highlight"><c- n>T2</c-></code>. This happens when one type has both a larger range and a lower precision than the other. -- <em>end note</em> ]</p>
    <p>Floating-point types that have equal floating-point conversion ranks are ordered by <em>floating-point conversion subrank</em>.  The subrank forms a total order among types with equal ranks.  The types <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float16_t</c-></code>, <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float32_t</c-></code>, <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code>, and <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float128_t</c-></code> ([stdfloat.types]) have a greater conversion subrank than any standard floating-point type with equal conversion rank. Otherwise, the conversion subrank order is implementation defined.</p>
    <p>[ <em>Note</em>: The floating-point conversion rank and subrank are used in the definition of the usual arithmetic conversions ([expr.arith.conv]). -- <em>end note</em> ]</p>
   </blockquote>
   <h4 class="heading settled" data-level="8.1.3" id="implicit-wording"><span class="secno">8.1.3. </span><span class="content">Implicit conversions</span><a class="self-link" href="#implicit-wording"></a></h4>
   <p><i>Design: <a href="#implicit">§ 5.5 Implicit conversions</a></i></p>
   <p>Modify section 7.3.9 "Floating-point conversions" [<strong>conv.double</strong>] as follows:</p>
   <blockquote>
    <p>
     A prvalue of floating-point type can be converted to a prvalue of another floating-point type 
     <ins>with a greater or equal conversion rank ([conv.rank]). A prvalue of standard floating-point type can be converted to a prvalue of another standard floating-point type</ins>
     .
    </p>
    <p>If the source value can be exactly represented in the destination type, the result of the conversion is that exact representation. If the source value is between two adjacent destination values, the result of the conversion is an implementation-defined choice of either of those values. Otherwise, the behavior is undefined.</p>
    <p>The conversions allowed as floating-point promotions are excluded from the set of floating-point conversions.</p>
   </blockquote>
   <p>In section 7.6.1.8 "Static cast" [<strong>expr.static.cast</strong>], add a new paragraph after paragraph 10 ("A value of integral or enumeration type can [...]"):</p>
   <blockquote>
    <div class="ins"> A prvalue of floating-point type can be explicitly converted to any other floating-point type.  If the source value can be exactly represented in the destination type, the result of the conversion has that exact representation. If the source value is between two adjacent destination values, the result of the conversion is an implementation-defined choice of either of those values. Otherwise, the behavior is undefined. </div>
   </blockquote>
   <p><em>Editorial note</em>: A <code class="highlight"><c- k>static_cast</c-></code> from a higher floating-point conversion rank to a lower conversion rank is already covered by [expr.static.cast] p7, which talks about inverses of standard conversions.  The new paragraph is necessary to allow explicit conversions between types with unordered conversion ranks.  The wording about what to do with the value is stolen from the floating-point conversions section [conv.double].</p>
   <h4 class="heading settled" data-level="8.1.4" id="arithmetic-wording"><span class="secno">8.1.4. </span><span class="content">Usual arithmetic conversions</span><a class="self-link" href="#arithmetic-wording"></a></h4>
   <p><i>Design: <a href="#arithmetic">§ 5.6 Usual arithmetic conversions</a></i></p>
   <p>Modify section 7.4 "Usual arithmetic conversions" [<strong>expr.arith.conv</strong>] as follows:</p>
   <p><em>Editorial note</em>: This includes a drive-by fix of removing "shall" from otherwise unchanged parts of this section.</p>
   <blockquote>
    <div class="numbered">
      Many binary operators that expect operands of arithmetic or enumeration type cause conversions and yield result types in a similar way. The purpose is to yield a common type, which is also the type of the result. This pattern is called the <em>usual arithmetic conversions</em>, which are defined as follows: 
     <ul>
      <li data-md>
       <p>If either operand is of scoped enumeration type ([dcl.enum]), no conversions are performed; if the other operand does not have the same type, the expression is ill-formed.</p>
      <li data-md>
       <del>If either operand is of type long double, the other shall be converted to long double.</del>
      <li data-md>
       <del>Otherwise, if either operand is double, the other shall be converted to double.</del>
      <li data-md>
       <del>Otherwise, if either operand is float, the other shall be converted to float.</del>
      <li data-md>
       <ins>Otherwise, if either operand is of floating-point type, the following rules are applied:</ins>
       <ul>
        <li data-md>
         <ins>If both operands have the same type, no further conversion is needed.</ins>
        <li data-md>
         <ins>Otherwise, if one of the operands is of a non-floating-point type, that operand is converted to the type of the operand with the floating-point type.</ins>
        <li data-md>
         <ins>Otherwise, if the floating-point conversion ranks ([conv.rank]) of the types of the operands are ordered but not equal, then the operand of the type with the lesser floating-point conversion rank is converted to the type of the other operand.</ins>
        <li data-md>
         <ins>Otherwise, if the floating-point conversion ranks of the types of the operands are equal, then the operand with the lesser floating-point conversion subrank ([conv.rank]) is converted to the type of the other operand.</ins>
        <li data-md>
         <ins>Otherwise, the expression is ill-formed.</ins>
       </ul>
      <li data-md>
       <p>
        Otherwise, the integral promotions ([conv.prom]) 
        <del>shall be</del>
        <ins>are</ins>
         performed on both operands.(59) Then the following rules 
        <del>shall be</del>
        <ins>are</ins>
         applied to the promoted operands:
       </p>
       <ul>
        <li data-md>
         <p>If both operands have the same type, no further conversion is needed.</p>
        <li data-md>
         <p>
          Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank 
          <del>shall be</del>
          <ins>is</ins>
           converted to the type of the operand with greater rank.
         </p>
        <li data-md>
         <p>
          Otherwise, if the operand that has unsigned integer type has rank greater than or equal to the rank of the type of the other operand, the operand with signed integer type 
          <del>shall be</del>
          <ins>is</ins>
           converted to the type of the operand with unsigned integer type.
         </p>
        <li data-md>
         <p>
          Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, the operand with unsigned integer type 
          <del>shall be</del>
          <ins>is</ins>
           converted to the type of the operand with signed integer type.
         </p>
        <li data-md>
         <p>
          Otherwise, both operands 
          <del>shall be</del>
          <ins>are</ins>
           converted to the unsigned integer type corresponding to the type of the operand with signed integer type.
         </p>
       </ul>
     </ul>
    </div>
    <p></p>
    <div class="numbered"> If one operand is of enumeration type and the other operand is of a different enumeration type or a floating-point type, this behavior is deprecated (D.1). </div>
   </blockquote>
   <h4 class="heading settled" data-level="8.1.5" id="narrow-wording"><span class="secno">8.1.5. </span><span class="content">Narrowing conversions</span><a class="self-link" href="#narrow-wording"></a></h4>
   <p><i>Design: <a href="#narrow">§ 5.7 Narrowing conversions</a></i></p>
   <p>Modify the definition of narrowing conversions in 9.4.4 "List-initialization" [<strong>dcl.init.list</strong>] paragraph 7 item 2:</p>
   <blockquote>
    <div>
     <ul>
      <li data-md>
       <del>from <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> to <code class="highlight"><c- b>double</c-></code> or <code class="highlight"><c- b>float</c-></code>, or from <code class="highlight"><c- b>double</c-></code> to <code class="highlight"><c- b>float</c-></code></del>
       <ins>from a floating-point type <code class="highlight"><c- n>T</c-></code> to another floating-point type whose floating-point conversion rank is neither greater than nor equal to that of <code class="highlight"><c- n>T</c-></code></ins>
       , except where the source is a constant expression and the actual value after conversion is within the range of values that can be represented (even if it cannot be represented exactly), or
     </ul>
    </div>
   </blockquote>
   <h4 class="heading settled" data-level="8.1.6" id="overload-wording"><span class="secno">8.1.6. </span><span class="content">Overload resolution</span><a class="self-link" href="#overload-wording"></a></h4>
   <p><i>Design: <a href="#overload">§ 5.8 Overload resolution</a></i></p>
   <p>In 12.4.3.2 "Ranking implicit conversion sequences" [<strong>over.ics.rank</strong>] paragraph 4, add a new bullet between (4.2) and (4.3):</p>
   <blockquote>
    <ul>
     <li data-md>
      <p>(4.2) A conversion that promotes an enumeration whose underlying type is fixed to its underlying type is better than one that promotes to the promoted underlying type, if the two are different.</p>
     <li data-md>
      <ins>
       (4.3) A conversion from floating-point type <code class="highlight"><c- n>FP1</c-></code> to floating-point type <code class="highlight"><c- n>FP2</c-></code> is better than a conversion from <code class="highlight"><c- n>FP1</c-></code> to floating-point type <code class="highlight"><c- n>FP3</c-></code> if 
       <ul>
        <li data-md>
         <p>(4.3.1) the floating-point conversion rank ([conv.rank]) of <code class="highlight"><c- n>FP1</c-></code> is equal to the rank of <code class="highlight"><c- n>FP2</c-></code>, and</p>
        <li data-md>
         <p>(4.3.2) the rank of <code class="highlight"><c- n>FP1</c-></code> is not equal to the rank of <code class="highlight"><c- n>FP3</c-></code> or the floating-point conversion subrank ([conv.rank]) of <code class="highlight"><c- n>FP2</c-></code> is greater than the subrank of <code class="highlight"><c- n>FP3</c-></code>.</p>
       </ul>
      </ins>
     <li data-md>
      <del>(4.3)</del>
      <ins>(4.4)</ins>
       If class <code class="highlight"><c- n>B</c-></code> is derived directly or indirectly from class <code class="highlight"><c- n>A</c-></code>, conversion of <code class="highlight"><c- n>B</c-><c- o>*</c-></code> to <code class="highlight"><c- n>A</c-><c- o>*</c-></code> is better than conversion of <code class="highlight"><c- n>B</c-><c- o>*</c-></code> to <code class="highlight"><c- b>void</c-><c- o>*</c-></code>, and conversion of <code class="highlight"><c- n>A</c-><c- o>*</c-></code> to <code class="highlight"><c- b>void</c-><c- o>*</c-></code> is better than conversion of <code class="highlight"><c- n>B</c-><c- o>*</c-></code> to <code class="highlight"><c- b>void</c-><c- o>*</c-></code>. 
    </ul>
   </blockquote>
   <h3 class="heading settled" data-level="8.2" id="wording-library"><span class="secno">8.2. </span><span class="content">Library</span><a class="self-link" href="#wording-library"></a></h3>
   <h4 class="heading settled" data-level="8.2.1" id="stdfloat-wording"><span class="secno">8.2.1. </span><span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>stdfloat</c-><c- o>></c-></code></span><a class="self-link" href="#stdfloat-wording"></a></h4>
   <p><i>Design: <a href="#alias">§ 7 Type aliases</a></i></p>
   <p><strong>TODO</strong>: This wording is preliminary and still needs a lot of work.  Need wording for adding <code class="highlight"><c- o>&lt;</c-><c- n>stdfloat</c-><c- o>></c-></code> to the list of headers.</p>
   <p>Add a new section to 17 "Language support library" [<strong>support</strong>] at the level of [<strong>cstdint</strong>] just after [<strong>cstdint</strong>].  The section has the stable name [<strong>stdfloat</strong>] with three subsections, [<strong>stdfloat.syn</strong>], [<strong>stdfloat.types</strong>], and [<strong>stdfloat.literals</strong>].</p>
   <blockquote class="ins">
    <big>
     <big><b>17.x Floating-point types [stdfloat]</b></big>
    </big>
    <br> 
    <big><b>17.x.1 Header <code class="highlight"><c- o>&lt;</c-><c- n>stdfloat</c-><c- o>></c-></code> synopsis [stdfloat.syn]</b></big>
<pre class="highlight"><code class="highlight"><c- k><c- k>namespace</c-></c-> <c- n><c- n>std</c-></c-> <c- p><c- p>{</c-></c->
    <c- k><c- k>using</c-></c-> <c- n><c- n>float16_t</c-></c->  <c- o><c- o>=</c-></c-> <em><c- n><c- n>extended</c-></c-> <c- n><c- n>floating</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>point</c-></c-> <c- n><c- n>type</c-></c-></em><c- p><c- p>;</c-></c-> <c- c1><c- c1>// </c-></c-><em><c- c1><c- c1>optional</c-></c-></em>
    <c- k><c- k>using</c-></c-> <c- n><c- n>float32_t</c-></c->  <c- o><c- o>=</c-></c-> <em><c- n><c- n>extended</c-></c-> <c- n><c- n>floating</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>point</c-></c-> <c- n><c- n>type</c-></c-></em><c- p><c- p>;</c-></c-> <c- c1><c- c1>// </c-></c-><em><c- c1><c- c1>optional</c-></c-></em>
    <c- k><c- k>using</c-></c-> <c- n><c- n>float64_t</c-></c->  <c- o><c- o>=</c-></c-> <em><c- n><c- n>extended</c-></c-> <c- n><c- n>floating</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>point</c-></c-> <c- n><c- n>type</c-></c-></em><c- p><c- p>;</c-></c-> <c- c1><c- c1>// </c-></c-><em><c- c1><c- c1>optional</c-></c-></em>
    <c- k><c- k>using</c-></c-> <c- n><c- n>float128_t</c-></c-> <c- o><c- o>=</c-></c-> <em><c- n><c- n>extended</c-></c-> <c- n><c- n>floating</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>point</c-></c-> <c- n><c- n>type</c-></c-></em><c- p><c- p>;</c-></c-> <c- c1><c- c1>// </c-></c-><em><c- c1><c- c1>optional</c-></c-></em>
    <c- k><c- k>using</c-></c-> <c- n><c- n>bfloat16_t</c-></c-> <c- o><c- o>=</c-></c-> <em><c- n><c- n>extended</c-></c-> <c- n><c- n>floating</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>point</c-></c-> <c- n><c- n>type</c-></c-></em><c- p><c- p>;</c-></c-> <c- c1><c- c1>// </c-></c-><em><c- c1><c- c1>optional</c-></c-></em>

  <c- kr><c- kr>inline</c-></c-> <c- k><c- k>namespace</c-></c-> <c- n><c- n>literals</c-></c-> <c- p><c- p>{</c-></c->
  <c- kr><c- kr>inline</c-></c-> <c- k><c- k>namespace</c-></c-> <c- n><c- n>float_literals</c-></c-> <c- p><c- p>{</c-></c->
    <c- k><c- k>constexpr</c-></c-> <c- n><c- n>float16_t</c-></c->  <c- k><c- k>operator</c-></c-><c- s><c- s>""</c-></c-> <c- n><c- n>f16</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-><c- p><c- p>)</c-></c-> <c- k><c- k>noexcept</c-></c-><c- p><c- p>;</c-></c->        <c- c1><c- c1>// </c-></c-><em><c- c1><c- c1>optional</c-></c-></em>
    <c- k><c- k>constexpr</c-></c-> <c- n><c- n>float32_t</c-></c->  <c- k><c- k>operator</c-></c-><c- s><c- s>""</c-></c-> <c- n><c- n>f32</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-><c- p><c- p>)</c-></c-> <c- k><c- k>noexcept</c-></c-><c- p><c- p>;</c-></c->        <c- c1><c- c1>// </c-></c-><em><c- c1><c- c1>optional</c-></c-></em>
    <c- k><c- k>constexpr</c-></c-> <c- n><c- n>float64_t</c-></c->  <c- k><c- k>operator</c-></c-><c- s><c- s>""</c-></c-> <c- n><c- n>f64</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-><c- p><c- p>)</c-></c-> <c- k><c- k>noexcept</c-></c-><c- p><c- p>;</c-></c->        <c- c1><c- c1>// </c-></c-><em><c- c1><c- c1>optional</c-></c-></em>
    <c- k><c- k>constexpr</c-></c-> <c- n><c- n>float128_t</c-></c-> <c- k><c- k>operator</c-></c-><c- s><c- s>""</c-></c-> <c- n><c- n>f128</c-></c-><c- p><c- p>(</c-></c-><i><c- n><c- n>literal</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>arg</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>type</c-></c-></i><c- p><c- p>)</c-></c-> <c- k><c- k>noexcept</c-></c-><c- p><c- p>;</c-></c->  <c- c1><c- c1>// </c-></c-><em><c- c1><c- c1>optional</c-></c-></em>
    <c- k><c- k>constexpr</c-></c-> <c- n><c- n>bfloat16_t</c-></c-> <c- k><c- k>operator</c-></c-><c- s><c- s>""</c-></c-> <c- n><c- n>bf16</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-><c- p><c- p>)</c-></c-> <c- k><c- k>noexcept</c-></c-><c- p><c- p>;</c-></c->       <c- c1><c- c1>// </c-></c-><em><c- c1><c- c1>optional</c-></c-></em>
  <c- p><c- p>}</c-></c->
  <c- p><c- p>}</c-></c->
<c- p><c- p>}</c-></c->
</code></pre>
    <p>The header defines conditionally-supported names and literal suffixes for certain extended floating-point types.  Each type alias and each corresponding literal suffix is defined only if the implementation supports the specified extended floating-point type. [<em>Note</em>: On some conforming implementations that do not support any extended floating-point types the <code class="highlight"><c- o>&lt;</c-><c- n>stdfloat</c-><c- o>></c-></code> header could contain only empty namespace definitions. -- <em>end note</em> ]</p>
    <big><b>17.x.2 Extended floating-point type aliases [stdfloat.types]</b></big>
    <p>ISO/IEC/IEEE 60559 specifies interchangable formats for binary floating-point types.
These formats can be identified by their storage width in bits <code class="highlight"><c- n>N</c-></code>, precision in bits <code class="highlight"><c- n>p</c-></code> and maximum exponent <code class="highlight"><c- n>emax</c-></code>.</p>
    <p>The following table provides the parameters for extended format types:</p>
    <table>
     <thead>
      <tr>
       <td>Parameter 
       <td><code class="highlight"><c- n>float16_t</c-></code>
       <td><code class="highlight"><c- n>float32_t</c-></code>
       <td><code class="highlight"><c- n>float64_t</c-></code>
       <td><code class="highlight"><c- n>float128_t</c-></code>
       <td><code class="highlight"><c- n>bfloat16_t</c-></code>
     <tbody>
      <tr>
       <td>storage width in bits <em>N</em>
       <td>16
       <td>32
       <td>64
       <td>128
       <td>16
      <tr>
       <td>precision in bits <em>p</em> 
       <td>11
       <td>24
       <td>53
       <td>113
       <td>8
      <tr>
       <td>maximum exponent <em>emax</em> 
       <td>15
       <td>127
       <td>1023
       <td>16383
       <td>127
    </table>
    <p>[ <em>Note</em>:</p>
    <ul>
     <li data-md>
      <p><code class="highlight"><c- n>float16_t</c-></code> type adheres to <code class="highlight"><c- n>binary16</c-></code> ISO/IEC/IEEE 60559,</p>
     <li data-md>
      <p><code class="highlight"><c- n>float32_t</c-></code> type adheres to <code class="highlight"><c- n>binary32</c-></code> ISO/IEC/IEEE 60559,</p>
     <li data-md>
      <p><code class="highlight"><c- n>float64_t</c-></code> type adheres to <code class="highlight"><c- n>binary64</c-></code> ISO/IEC/IEEE 60559,</p>
     <li data-md>
      <p><code class="highlight"><c- n>float128_t</c-></code> type adheres to <code class="highlight"><c- n>binary128</c-></code> ISO/IEC/IEEE 60559,</p>
     <li data-md>
      <p><code class="highlight"><c- n>bfloat16_t</c-></code> type is not part of ISO/IEC/IEEE 60559. -- <em>end note</em>]</p>
    </ul>
    <p><code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>numeric_limits</c-><c- o>&lt;</c-><em><c- n>floating</c-><c- o>-</c-><c- n>point</c-> <c- n>type</c-></em><c- o>>::</c-><c- n>is_iec559</c-></code> is <code class="highlight">true</code> when <em>floating-point-type</em> is either <code class="highlight"><c- n>float16_t</c-></code>, <code class="highlight"><c- n>float32_t</c-></code>, <code class="highlight"><c- n>float64_t</c-></code>, or <code class="highlight"><c- n>float128_t</c-></code>.</p>
    <big><b>17.x.3 Extended floating-point type literal suffixes [stdfloat.literals]</b></big>
    <p>This subclause describes literal suffixes for constructing extended floating-point number literals. The suffixes <code class="highlight"><c- n>f16</c-></code>, <code class="highlight"><c- n>f32</c-></code>, <code class="highlight"><c- n>f64</c-></code>, <code class="highlight"><c- n>f128</c-></code>, and <code class="highlight"><c- n>bf16</c-></code> create floating-point numbers of the extended floating-point types <code class="highlight"><c- n>float16_t</c-></code>, <code class="highlight"><c- n>float32_t</c-></code>, <code class="highlight"><c- n>float64_t</c-></code>, <code class="highlight"><c- n>float128_t</c-></code>, and <code class="highlight"><c- n>bfloat16_t</c-></code> respectively. <i>literal-arg-type</i> is <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> if <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> has an equal or greater conversion rank as the target type, or <code class="highlight"><c- k>const</c-> <c- b>char</c-> <c- o>*</c-></code> otherwise.  If the argument is of <code class="highlight"><c- k>const</c-> <c- b>char</c-> <c- o>*</c-></code> type, it is interpreted as an integer literal without integer suffix or floating-point literal without floating-point suffix.  If implementation supports an extended floating-point type, it provides the corresponding literal suffix.</p>
    <p><code class="highlight"></code></p>
<pre class="highlight"><code class="highlight"><c- k><c- k>namespace</c-></c-> <c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- kr><c- kr>inline</c-></c-> <c- n><c- n>literals</c-></c-><c- o><c- o>::</c-></c-><c- kr><c- kr>inline</c-></c-> <c- n><c- n>float_literals</c-></c-> <c- p><c- p>{</c-></c->
    <c- k><c- k>constexpr</c-></c-> <c- n><c- n>float16_t</c-></c-> <c- k><c- k>operator</c-></c-><c- s><c- s>""</c-></c-> <c- n><c- n>f16</c-></c-> <c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>arg</c-></c-><c- p><c- p>)</c-></c-> <c- k><c- k>noexcept</c-></c-><c- p><c- p>;</c-></c->
<c- p><c- p>}</c-></c->
</code></pre>
    <p></p>
    <p><em>Returns</em>: <code class="highlight"><c- k>static_cast</c-><c- o>&lt;</c-><c- n>float16_t</c-><c- o>></c-><c- p>(</c-><c- n>arg</c-><c- p>)</c-></code>.</p>
    <p><code class="highlight"></code></p>
<pre class="highlight"><code class="highlight"><c- k><c- k>namespace</c-></c-> <c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- kr><c- kr>inline</c-></c-> <c- n><c- n>literals</c-></c-><c- o><c- o>::</c-></c-><c- kr><c- kr>inline</c-></c-> <c- n><c- n>float_literals</c-></c-> <c- p><c- p>{</c-></c->
    <c- k><c- k>constexpr</c-></c-> <c- n><c- n>float32_t</c-></c-> <c- k><c- k>operator</c-></c-><c- s><c- s>""</c-></c-> <c- n><c- n>f32</c-></c-> <c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>arg</c-></c-><c- p><c- p>)</c-></c-> <c- k><c- k>noexcept</c-></c-><c- p><c- p>;</c-></c->
<c- p><c- p>}</c-></c->
</code></pre>
    <p></p>
    <p><em>Returns</em>: <code class="highlight"><c- k>static_cast</c-><c- o>&lt;</c-><c- n>float32_t</c-><c- o>></c-><c- p>(</c-><c- n>arg</c-><c- p>)</c-></code>.</p>
    <p><code class="highlight"></code></p>
<pre class="highlight"><code class="highlight"><c- k><c- k>namespace</c-></c-> <c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- kr><c- kr>inline</c-></c-> <c- n><c- n>literals</c-></c-><c- o><c- o>::</c-></c-><c- kr><c- kr>inline</c-></c-> <c- n><c- n>float_literals</c-></c-> <c- p><c- p>{</c-></c->
    <c- k><c- k>constexpr</c-></c-> <c- n><c- n>float64_t</c-></c-> <c- k><c- k>operator</c-></c-><c- s><c- s>""</c-></c-> <c- n><c- n>f64</c-></c-> <c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>arg</c-></c-><c- p><c- p>)</c-></c-> <c- k><c- k>noexcept</c-></c-><c- p><c- p>;</c-></c->
<c- p><c- p>}</c-></c->
</code></pre>
    <p></p>
    <p><em>Returns</em>: <code class="highlight"><c- k>static_cast</c-><c- o>&lt;</c-><c- n>float64_t</c-><c- o>></c-><c- p>(</c-><c- n>arg</c-><c- p>)</c-></code>.</p>
    <p><code class="highlight"></code></p>
<pre class="highlight"><code class="highlight"><c- k><c- k>namespace</c-></c-> <c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- kr><c- kr>inline</c-></c-> <c- n><c- n>literals</c-></c-><c- o><c- o>::</c-></c-><c- kr><c- kr>inline</c-></c-> <c- n><c- n>float_literals</c-></c-> <c- p><c- p>{</c-></c->
    <c- k><c- k>constexpr</c-></c-> <c- n><c- n>float128_t</c-></c-> <c- k><c- k>operator</c-></c-><c- s><c- s>""</c-></c-> <c- n><c- n>f128</c-></c-> <c- p><c- p>(</c-></c-><i><c- n><c- n>literal</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>arg</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>type</c-></c-></i> <c- n><c- n>arg</c-></c-><c- p><c- p>);</c-></c->
<c- p><c- p>}</c-></c->
</code></pre>
    <p></p>
    <p><em>Returns</em>: If <code class="highlight"><em><c- n>literal</c-><c- o>-</c-><c- n>arg</c-><c- o>-</c-><c- n>type</c-></em></code> is <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>, <code class="highlight"><c- k>static_cast</c-><c- o>&lt;</c-><c- n>float128_t</c-><c- o>></c-><c- p>(</c-><c- n>arg</c-><c- p>)</c-></code>.  If <code class="highlight"><em><c- n>literal</c-><c- o>-</c-><c- n>arg</c-><c- o>-</c-><c- n>type</c-></em></code> is <code class="highlight"><c- k>const</c-> <c- b>char</c-><c- o>*</c-></code>, the result of interpreting <code class="highlight"><c- n>arg</c-></code> as a floating-point number, or <code class="highlight"><c- n>numeric_limits</c-><c- o>&lt;</c-><c- n>float128_t</c-><c- o>>::</c-><c- n>infinity</c-><c- p>()</c-></code> if that floating-point value is greater than <code class="highlight"><c- n>numeric_limits</c-><c- o>&lt;</c-><c- n>float128_t</c-><c- o>>::</c-><c- n>max</c-><c- p>()</c-></code>.</p>
    <p><em>Remarks</em>: The program is ill-formed if <code class="highlight"><em><c- n>literal</c-><c- o>-</c-><c- n>arg</c-><c- o>-</c-><c- n>type</c-></em></code> is <code class="highlight"><c- k>const</c-> <c- b>char</c-><c- o>*</c-></code> and <code class="highlight"><c- n>arg</c-></code> does not represent a floating-point value.</p>
    <p><code class="highlight"></code></p>
<pre class="highlight"><code class="highlight"><c- k><c- k>namespace</c-></c-> <c- n><c- n>std</c-></c-><c- o><c- o>::</c-></c-><c- kr><c- kr>inline</c-></c-> <c- n><c- n>literals</c-></c-><c- o><c- o>::</c-></c-><c- kr><c- kr>inline</c-></c-> <c- n><c- n>float_literals</c-></c-> <c- p><c- p>{</c-></c->
    <c- k><c- k>constexpr</c-></c-> <c- n><c- n>bfloat16_t</c-></c-> <c- k><c- k>operator</c-></c-><c- s><c- s>""</c-></c-> <c- n><c- n>bf16</c-></c-> <c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>arg</c-></c-><c- p><c- p>)</c-></c-> <c- k><c- k>noexcept</c-></c-><c- p><c- p>;</c-></c->
<c- p><c- p>}</c-></c->
</code></pre>
    <p></p>
    <p><em>Returns</em>: <code class="highlight"><c- k>static_cast</c-><c- o>&lt;</c-><c- n>bfloat16_t</c-><c- o>></c-><c- p>(</c-><c- n>arg</c-><c- p>)</c-></code>.</p>
   </blockquote>
   <h4 class="heading settled" data-level="8.2.2" id="charconv-wording"><span class="secno">8.2.2. </span><span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>charconv</c-><c- o>></c-></code></span><a class="self-link" href="#charconv-wording"></a></h4>
   <p><i>Design: <a href="#charconv">§ 6.2 &lt;charconv></a></i></p>
   <p>Add a new paragraph to the beginning of 20.19.1 "Header <code class="highlight"><c- o>&lt;</c-><c- n>charconv</c-><c- o>></c-></code> synopsis" [<strong>charconv.syn</strong>], before the start of the synopsis:</p>
   <blockquote class="ins"> When a function has a parameter of type <code class="highlight"><em><c- n>integral</c-></em></code>, the implementation provides overloads for all signed and unsigned integer types and <code class="highlight"><c- b>char</c-></code> as the parameter type.  When a function has a parameter of type <code class="highlight"><em><c- n>floating</c-><c- o>-</c-><c- n>point</c-></em></code>, the implementation provides overloads for all floating-point types as the parameter type. </blockquote>
   <p>Change the header synopsis in [<strong>charconv.syn</strong>] as follows:</p>
   <blockquote>
<pre class="highlight"><code class="highlight">  <c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <del><em><c- n><c- n>see</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>below</c-></c-></em></del><ins><em><c- n><c- n>integral</c-></c-></em></ins> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>int</c-></c-> <c- n><c- n>base</c-></c-> <c- o><c- o>=</c-></c-> <c- mi><c- mi>10</c-></c-><c- p><c- p>);</c-></c->
  <c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <del><c- n><c- n>float</c-></c-></del><ins><em><c- n><c- n>floating</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>point</c-></c-></em></ins> <c- n><c- n>value</c-></c-><c- p><c- p>);</c-></c->
<del>  <c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>);</c-></c->
  <c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>);</c-></c-></del>
  <c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <del><c- n><c- n>float</c-></c-></del><ins><em><c- n><c- n>floating</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>point</c-></c-></em></ins> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c->
                           <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-><c- p><c- p>);</c-></c->
<del>  <c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-><c- p><c- p>);</c-></c->
  <c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-><c- p><c- p>);</c-></c-></del>
  <c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <del><c- n><c- n>float</c-></c-></del><ins><em><c- n><c- n>floating</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>point</c-></c-></em></ins> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c->
                           <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>int</c-></c-> <c- n><c- n>precision</c-></c-><c- p><c- p>);</c-></c->
<del>  <c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c->
                           <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>int</c-></c-> <c- n><c- n>precision</c-></c-><c- p><c- p>);</c-></c->
  <c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c->
                           <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>int</c-></c-> <c- n><c- n>precision</c-></c-><c- p><c- p>);</c-></c-></del>

  <c- c1><c- c1>// ...</c-></c->

  <c- n><c- n>from_chars_result</c-></c-> <c- nf><c- nf>from_chars</c-></c-><c- p><c- p>(</c-></c-><c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c->
                               <del><em><c- n><c- n>see</c-></c-> <c- n><c- n>below</c-></c-></em></del><ins><em><c- n><c- n>integral</c-></c-></em></ins><c- o><c- o>&amp;</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>int</c-></c-> <c- n><c- n>base</c-></c-> <c- o><c- o>=</c-></c-> <c- mi><c- mi>10</c-></c-><c- p><c- p>);</c-></c->

  <c- n><c- n>from_chars_result</c-></c-> <c- nf><c- nf>from_chars</c-></c-><c- p><c- p>(</c-></c-><c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <del><c- n><c- n>float</c-></c-></del><ins><em><c- n><c- n>floating</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>point</c-></c-></em></ins><c- o><c- o>&amp;</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c->
                               <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>chars_format</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>general</c-></c-><c- p><c- p>);</c-></c->
<del>  <c- n><c- n>from_chars_result</c-></c-> <c- nf><c- nf>from_chars</c-></c-><c- p><c- p>(</c-></c-><c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c->
                               <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>chars_format</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>general</c-></c-><c- p><c- p>);</c-></c->
  <c- n><c- n>from_chars_result</c-></c-> <c- nf><c- nf>from_chars</c-></c-><c- p><c- p>(</c-></c-><c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c->
                               <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>chars_format</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>general</c-></c-><c- p><c- p>);</c-></c-></del>
</code></pre>
   </blockquote>
   <p>In 20.19.2 "Primitive numeric output conversion" [<strong>charconv.to.chars</strong>], leave the first three paragraphs unchanged, but modify the rest of the section as follows:</p>
   <blockquote>
<pre class="highlight"><code class="highlight"><c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <del><em><c- n><c- n>see</c-></c-> <c- n><c- n>below</c-></c-></em></del><ins><em><c- n><c- n>integral</c-></c-></em></ins> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>int</c-></c-> <c- n><c- n>base</c-></c-> <c- o><c- o>=</c-></c-> <c- mi><c- mi>10</c-></c-><c- p><c- p>);</c-></c-></code></pre>
    <p><em>Preconditions</em>: <code class="highlight"><c- n>base</c-></code> has a value between 2 and 36 (inclusive).</p>
    <p><em>Effects</em>: The value of <code class="highlight"><c- n>value</c-></code> is converted to a string of digits in the given base (with no redundant leading zeroes). Digits inthe range 10..35 (inclusive) are represented as lowercase characters <code class="highlight"><c- n>a</c-></code>..<code class="highlight"><c- n>z</c-></code>. If <code class="highlight"><c- n>value</c-></code> isless than zero, the representation starts with <code class="highlight"><c- sc>'-'</c-></code>.</p>
    <p><em>Throws</em>: Nothing.</p>
    <del><em>Remarks</em>:</del>
    <ins>[ <em>Note</em>:</ins>
     The implementation 
    <del>shall provide</del>
    <ins>provides</ins>
     overloads for all signed and unsigned integer types and <code class="highlight"><c- b>char</c-></code> as the type of the parameter <code class="highlight"><c- n>value</c-></code>. 
    <ins>- <em>end note</em> ]</ins>
<pre class="highlight"><code class="highlight"><c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <del><c- n><c- n>float</c-></c-></del><ins><em><c- n><c- n>floating</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>point</c-></c-></em></ins> <c- n><c- n>value</c-></c-><c- p><c- p>);</c-></c->
<del><c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>);</c-></c-></del>
</code></pre>
    <p><em>Effects</em>: <code class="highlight"><c- n>value</c-></code> is converted to a string in the style of <code class="highlight"><c- n>printf</c-></code> in the "C" locale. The conversion specifier is <code class="highlight"><c- n>f</c-></code> or <code class="highlight"><c- n>e</c-></code>, chosen according to the requirement for a shortest representation (see above); a tie is resolved in favor of <code class="highlight"><c- n>f</c-></code>.</p>
    <p><em>Throws</em>: Nothing.</p>
    <ins>[ <em>Note</em>: The implementation provides overloads for all floating-point types as the type of the parameter <code class="highlight"><c- n>value</c-></code>. - <em>end note</em> ]</ins>
<pre class="highlight"><code class="highlight"><c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <del><c- n><c- n>float</c-></c-></del><ins><em><c- n><c- n>floating</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>point</c-></c-></em></ins> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-><c- p><c- p>);</c-></c->
<del><c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-><c- p><c- p>);</c-></c-></del>
</code></pre>
    <p><em>Preconditions</em>: <code class="highlight"><c- n>fmt</c-></code> has the value of one of the enumerators of <code class="highlight"><c- n>chars_format</c-></code>.</p>
    <p><em>Effects</em>: <code class="highlight"><c- n>value</c-></code> is converted to a string in the style of <code class="highlight"><c- n>printf</c-></code> in the "C" locale.</p>
    <p><em>Throws</em>: Nothing.</p>
    <ins>[ <em>Note</em>: The implementation provides overloads for all floating-point types as the type of the parameter <code class="highlight"><c- n>value</c-></code>. - <em>end note</em> ]</ins>
<pre class="highlight"><code class="highlight"><c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <del><c- n><c- n>float</c-></c-></del><ins><em><c- n><c- n>floating</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>point</c-></c-></em></ins> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c->
                         <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>int</c-></c-> <c- n><c- n>precision</c-></c-><c- p><c- p>);</c-></c->
<del><c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c->
                         <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>int</c-></c-> <c- n><c- n>precision</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>to_chars_result</c-></c-> <c- nf><c- nf>to_chars</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c->
                         <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>int</c-></c-> <c- n><c- n>precision</c-></c-><c- p><c- p>);</c-></c-></del>
</code></pre>
    <p><em>Preconditions</em>: <code class="highlight"><c- n>fmt</c-></code> has the value of one of the enumerators of <code class="highlight"><c- n>chars_format</c-></code>.</p>
    <p><em>Effects</em>: <code class="highlight"><c- n>value</c-></code> is converted to a string in the style of <code class="highlight"><c- n>printf</c-></code> in the "C" locale with the given precision.</p>
    <p><em>Throws</em>: Nothing.</p>
    <ins>[ <em>Note</em>: The implementation provides overloads for all floating-point types as the type of the parameter <code class="highlight"><c- n>value</c-></code>. - <em>end note</em> ]</ins>
    <p>See also: ISO C 7.21.6.1</p>
   </blockquote>
   <p>Modify 20.19.3 "Primitive numeric input conversion" [<strong>charconv.from.chars</strong>] as follows:</p>
   <blockquote>
    <div class="numbered"> All functions named <code class="highlight"><c- n>from_chars</c-></code> analyze the string <code class="highlight"><c- p>[</c-><c- n>first</c-><c- p>,</c-> <c- n>last</c-><c- p>)</c-></code> for a pattern, where <code class="highlight"><c- p>[</c-><c- n>first</c-><c- p>,</c-> <c- n>last</c-><c- p>)</c-></code> is required to be a valid range. If no characters match the pattern, <code class="highlight"><c- n>value</c-></code> is unmodified, the member <code class="highlight"><c- n>ptr</c-></code> of the return value is <code class="highlight"><c- n>first</c-></code> and the member <code class="highlight"><c- n>ec</c-></code> is equal to <code class="highlight"><c- n>errc</c->​<c- o>::</c->​<c- n>invalid_argument</c-></code>. [ <em>Note</em>: If the pattern allows for an optional sign, but the string has no digit characters following the sign, no characters match the pattern. — <em>end note</em> ] Otherwise, the characters matching the pattern are interpreted as a representation of a value of the type of <code class="highlight"><c- n>value</c-></code>. The member <code class="highlight"><c- n>ptr</c-></code> of the return value points to the first character not matching the pattern, or has the value <code class="highlight"><c- n>last</c-></code> if all characters match. If the parsed value is not in the range representable by the type of <code class="highlight"><c- n>value</c-></code>, <code class="highlight"><c- n>value</c-></code> is unmodified and the member <code class="highlight"><c- n>ec</c-></code> of the return value is equal to <code class="highlight"><c- n>errc</c->​<c- o>::</c->​<c- n>result_out_of_range</c-></code>. Otherwise, <code class="highlight"><c- n>value</c-></code> is set to the parsed value, after rounding according to <code class="highlight"><c- n>round_to_nearest</c-></code>, and the member <code class="highlight"><c- n>ec</c-></code> is value-initialized. </div>
<pre class="highlight"><code class="highlight"><c- n><c- n>from_chars_result</c-></c-> <c- nf><c- nf>from_chars</c-></c-><c- p><c- p>(</c-></c-><c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c->
                             <del><em><c- n><c- n>see</c-></c-> <c- n><c- n>below</c-></c-></em></del><ins><em><c- n><c- n>integral</c-></c-></em></ins><c- o><c- o>&amp;</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>int</c-></c-> <c- n><c- n>base</c-></c-> <c- o><c- o>=</c-></c-> <c- mi><c- mi>10</c-></c-><c- p><c- p>);</c-></c->
</code></pre>
    <div class="numbered"> <em>Preconditions</em>: <code class="highlight"><c- n>base</c-></code> has a value between 2 and 36 (inclusive). </div>
    <div class="numbered"> <em>Effects</em>: The pattern is the expected form of the subject sequence in the <code class="highlight"><c- s>"C"</c-></code> locale for the given nonzero base, as described for <code class="highlight"><c- n>strtol</c-></code>, except that no <code class="highlight"><c- s>"0x"</c-></code> or <code class="highlight"><c- s>"0X"</c-></code> prefix shall appear if the value of <code class="highlight"><c- n>base</c-></code> is 16, and except that <code class="highlight"><c- sc>'-'</c-></code> is the only sign that may appear, and only if <code class="highlight"><c- n>value</c-></code> has a signed type. </div>
    <div class="numbered"> <em>Throws</em>: Nothing. </div>
    <div class="numbered">
     <del><em>Remarks</em>:</del>
     <ins>[ <em>Note</em>:</ins>
      The implementation 
     <del>shall provide</del>
     <ins>provides</ins>
      overloads for all signed and unsigned integer types and <code class="highlight"><c- b>char</c-></code> as the referenced type of the parameter <code class="highlight"><c- n>value</c-></code>. 
     <ins>- <em>end note</em> ]</ins>
    </div>
<pre class="highlight"><code class="highlight"><c- n><c- n>from_chars_result</c-></c-> <c- nf><c- nf>from_chars</c-></c-><c- p><c- p>(</c-></c-><c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <del><c- n><c- n>float</c-></c-></del><ins><em><c- n><c- n>floating</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>point</c-></c-></em></ins><c- o><c- o>&amp;</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c->
                             <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>chars_format</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>general</c-></c-><c- p><c- p>);</c-></c->
<del><c- n><c- n>from_chars_result</c-></c-> <c- nf><c- nf>from_chars</c-></c-><c- p><c- p>(</c-></c-><c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>double</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c->
                             <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>chars_format</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>general</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>from_chars_result</c-></c-> <c- nf><c- nf>from_chars</c-></c-><c- p><c- p>(</c-></c-><c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>first</c-></c-><c- p><c- p>,</c-></c-> <c- k><c- k>const</c-></c-> <c- b><c- b>char</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>last</c-></c-><c- p><c- p>,</c-></c-> <c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>value</c-></c-><c- p><c- p>,</c-></c->
                             <c- n><c- n>chars_format</c-></c-> <c- n><c- n>fmt</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>chars_format</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>general</c-></c-><c- p><c- p>);</c-></c-></del>
</code></pre>
    <div class="numbered"> <em>Preconditions</em>: <code class="highlight"><c- n>fmt</c-></code> has the value of one of the enumerators of <code class="highlight"><c- n>chars_format</c-></code>. </div>
    <div class="numbered">
      <em>Effects</em>: The pattern is the expected form of the subject sequence in the <code class="highlight"><c- s>"C"</c-></code> locale, as described for <code class="highlight"><c- n>strtod</c-></code>, except that 
     <ul>
      <li data-md>
       <p>the sign <code class="highlight"><c- sc>'+'</c-></code> may only appear in the exponent part;</p>
      <li data-md>
       <p>if <code class="highlight"><c- n>fmt</c-></code> has <code class="highlight"><c- n>chars_format</c-><c- o>::</c-><c- n>scientific</c-></code> set but not <code class="highlight"><c- n>chars_format</c-><c- o>::</c-><c- n>fixed</c-></code>, the otherwise optional exponent part shall appear;</p>
      <li data-md>
       <p>if <code class="highlight"><c- n>fmt</c-></code> has <code class="highlight"><c- n>chars_format</c-><c- o>::</c-><c- n>fixed</c-></code> set but not <code class="highlight"><c- n>chars_format</c-><c- o>::</c-><c- n>scientific</c-></code>, the optional exponent part shall not appear; and</p>
      <li data-md>
       <p>if <code class="highlight"><c- n>fmt</c-></code> is <code class="highlight"><c- n>chars_format</c-><c- o>::</c-><c- n>hex</c-></code>, the prefix <code class="highlight"><c- s>"0x"</c-></code> or <code class="highlight"><c- s>"0X"</c-></code> is assumed. [ <em>Example</em>: The string <code class="highlight"><c- mh>0x123</c-></code> is parsed to have the value <code class="highlight"><c- mi>0</c-></code> with remaining characters <code class="highlight"><c- n>x123</c-></code>. - <em>end example</em> ]</p>
     </ul>
     <p>In any case, the resulting <code class="highlight"><c- n>value</c-></code> is one of at most two floating-point values closest to the value of the string matching the pattern.</p>
    </div>
    <div class="numbered"> <em>Throws</em>: Nothing. </div>
    <div class="numbered">
     <ins>[ <em>Note</em>: The implementation provides overloads for all floating-point types as the referenced type of the parameter <code class="highlight"><c- n>value</c-></code>. - <em>end note</em> ]</ins>
    </div>
    <p>See also: ISO C 7.22.1.3, 7.22.1.4</p>
   </blockquote>
   <h4 class="heading settled" data-level="8.2.3" id="iostream-wording"><span class="secno">8.2.3. </span><span class="content">I/O Streams</span><a class="self-link" href="#iostream-wording"></a></h4>
   <p><i>Design: <a href="#iostream">§ 6.4 I/O Streams</a></i></p>
   <h5 class="heading settled" data-level="8.2.3.1" id="ostream-wording"><span class="secno">8.2.3.1. </span><span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>ostream</c-><c- o>></c-></code></span><a class="self-link" href="#ostream-wording"></a></h5>
   <p>Modify 29.7.5.2.1 "General" [<strong>ostream.general</strong>] as follows:</p>
   <p>Insert a new paragraph at the beginning of the section, before the synopsis:</p>
   <blockquote class="ins">
    <p>When a function has a parameter type <code class="highlight"><em><c- n>small</c-><c- o>-</c-><c- n>ext</c-><c- o>-</c-><c- n>fp</c-></em></code>, the implementation provides overloads for all extended floating-point types ([basic.fundamental]) whose floating-point conversion rank ([conv.rank]) is less than or equal to the conversion rank of <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>.  When a function has a parameter type <code class="highlight"><em><c- n>big</c-><c- o>-</c-><c- n>ext</c-><c- o>-</c-><c- n>fp</c-></em></code>, the implementation provides overloads for all extended floating-point types whose floating-point conversion rank is neither less than nor equal to the conversion rank of <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>.</p>
   </blockquote>
   <p>Modify the section of the synopsis for <code class="highlight"><c- k>operator</c-><c- o>&lt;&lt;</c-></code> as follows:</p>
   <blockquote>
<pre class="highlight"><code class="highlight"><c- c1><c- c1>// [ostream.formatted], formatted output</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- p><c- p>(</c-></c-><c- o><c- o>*</c-></c-><c- n><c- n>pf</c-></c-><c- p><c- p>)(</c-></c-><c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-><c- p><c- p>));</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>basic_ios</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>charT</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>traits</c-></c-><c- o><c- o>>&amp;</c-></c-> <c- p><c- p>(</c-></c-><c- o><c- o>*</c-></c-><c- n><c- n>pf</c-></c-><c- p><c- p>)(</c-></c-><c- n><c- n>basic_ios</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>charT</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>traits</c-></c-><c- o><c- o>>&amp;</c-></c-><c- p><c- p>));</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>ios_base</c-></c-><c- o><c- o>&amp;</c-></c-> <c- p><c- p>(</c-></c-><c- o><c- o>*</c-></c-><c- n><c- n>pf</c-></c-><c- p><c- p>)(</c-></c-><c- n><c- n>ios_base</c-></c-><c- o><c- o>&amp;</c-></c-><c- p><c- p>));</c-></c->

<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>bool</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>short</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>unsigned</c-></c-> <c- b><c- b>short</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>int</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>unsigned</c-></c-> <c- b><c- b>int</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>unsigned</c-></c-> <c- b><c- b>long</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>long</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>unsigned</c-></c-> <c- b><c- b>long</c-></c-> <c- b><c- b>long</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>float</c-></c-> <c- n><c- n>f</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>double</c-></c-> <c- n><c- n>f</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>f</c-></c-><c- p><c- p>);</c-></c->
<ins><c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><i><c- n><c- n>small</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>ext</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>fp</c-></c-></i> <c- n><c- n>f</c-></c-><c- p><c- p>);</c-></c-></ins>
<ins><c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><i><c- n><c- n>big</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>ext</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>fp</c-></c-></i> <c- n><c- n>f</c-></c-><c- p><c- p>)</c-></c-> <c- o><c- o>=</c-></c-> <c- k><c- k>delete</c-></c-><c- p><c- p>;</c-></c-></ins>

<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- k><c- k>const</c-></c-> <c- b><c- b>void</c-></c-><c- o><c- o>*</c-></c-> <c- n><c- n>p</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>nullptr_t</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>basic_streambuf</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>char_type</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>traits</c-></c-><c- o><c- o>>*</c-></c-> <c- n><c- n>sb</c-></c-><c- p><c- p>);</c-></c->
</code></pre>
   </blockquote>
   <p>Modify 29.7.5.3.2 "Arithmetic inserters" [<strong>ostream.inserters.arithmetic</strong>], adding the following at the end of the section:</p>
   <blockquote class="ins">
<pre class="highlight"><code class="highlight"><c- n><c- n>basic_ostream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>&lt;&lt;</c-></c-><c- p><c- p>(</c-></c-><i><c- n><c- n>small</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>ext</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>fp</c-></c-></i> <c- n><c- n>val</c-></c-><c- p><c- p>);</c-></c->
</code></pre>
    <p>[ <em>Note</em>: <code class="highlight"><em><c- n>small</c-><c- o>-</c-><c- n>ext</c-><c- o>-</c-><c- n>fp</c-></em></code> is an extended floating-point type whose floating-point conversion rank is less than or equal to the conversion rank of <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> ([ostream.general]). -- <em>end note</em> ]</p>
    <p><em>Effects</em>: When <code class="highlight"><c- n>val</c-></code> is of a type whose floating-point conversion rank is less than or equal to that of <code class="highlight"><c- b>double</c-></code>, the formatting conversion occurs as if it performed the following code fragment:</p>
<pre class="highlight"><code class="highlight"><c- b><c- b>bool</c-></c-> <c- n><c- n>failed</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>use_facet</c-></c-><c- o><c- o>&lt;</c-></c->
  <c- n><c- n>num_put</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>charT</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>ostreambuf_iterator</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>charT</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>traits</c-></c-><c- o><c- o>>></c-></c->
    <c- o><c- o>></c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>getloc</c-></c-><c- p><c- p>()).</c-></c-><c- n><c- n>put</c-></c-><c- p><c- p>(</c-></c-><c- o><c- o>*</c-></c-><c- k><c- k>this</c-></c-><c- p><c- p>,</c-></c-> <c- o><c- o>*</c-></c-><c- k><c- k>this</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>fill</c-></c-><c- p><c- p>(),</c-></c->
      <c- k><c- k>static_cast</c-></c-><c- o><c- o>&lt;</c-></c-><c- b><c- b>double</c-></c-><c- o><c- o>></c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>val</c-></c-><c- p><c- p>)).</c-></c-><c- n><c- n>failed</c-></c-><c- p><c- p>();</c-></c->
</code></pre>
    <p>Otherwise the formatting conversion occurs as if it performed the following code fragment:</p>
<pre class="highlight"><code class="highlight"><c- b><c- b>bool</c-></c-> <c- n><c- n>failed</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>use_facet</c-></c-><c- o><c- o>&lt;</c-></c->
  <c- n><c- n>num_put</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>charT</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>ostreambuf_iterator</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>charT</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>traits</c-></c-><c- o><c- o>>></c-></c->
    <c- o><c- o>></c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>getloc</c-></c-><c- p><c- p>()).</c-></c-><c- n><c- n>put</c-></c-><c- p><c- p>(</c-></c-><c- o><c- o>*</c-></c-><c- k><c- k>this</c-></c-><c- p><c- p>,</c-></c-> <c- o><c- o>*</c-></c-><c- k><c- k>this</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>fill</c-></c-><c- p><c- p>(),</c-></c->
      <c- k><c- k>static_cast</c-></c-><c- o><c- o>&lt;</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-><c- o><c- o>></c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>val</c-></c-><c- p><c- p>)).</c-></c-><c- n><c- n>failed</c-></c-><c- p><c- p>();</c-></c->
</code></pre>
    <p>If <code class="highlight"><c- n>failed</c-></code> is <code class="highlight">true</code> then does <code class="highlight"><c- n>setstate</c-><c- p>(</c-><c- n>badbit</c-><c- p>)</c-></code>, which may throw an exception, and returns.</p>
    <p><em>Returns:</em> <code class="highlight"><c- o>*</c-><c- k>this</c-></code>.</p>
   </blockquote>
   <h5 class="heading settled" data-level="8.2.3.2" id="istream-wording"><span class="secno">8.2.3.2. </span><span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>istream</c-><c- o>></c-></code></span><a class="self-link" href="#istream-wording"></a></h5>
   <p>Modify 29.7.4.2.1 "General" [<strong>istream.general</strong>] as follows:</p>
   <p>Insert a new paragraph at the beginning of the section, before the synopsis:</p>
   <blockquote class="ins">
    <p>When a function has a parameter type <code class="highlight"><em><c- n>small</c-><c- o>-</c-><c- n>ext</c-><c- o>-</c-><c- n>fp</c-></em></code>, the implementation provides overloads for all extended floating-point types ([basic.fundamental]) whose floating-point conversion rank ([conv.rank]) is less than or equal to the conversion rank of <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>.  When a function has a parameter type <code class="highlight"><em><c- n>big</c-><c- o>-</c-><c- n>ext</c-><c- o>-</c-><c- n>fp</c-></em></code>, the implementation provides overloads for all extended floating-point types whose floating-point conversion rank is neither less than nor equal to the conversion rank of <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>.</p>
   </blockquote>
   <p>Modify the section of the synopsis for <code class="highlight"><c- k>operator</c-><c- o>>></c-></code> as follows:</p>
   <blockquote>
<pre class="highlight"><code class="highlight"><c- c1><c- c1>// [istream.formatted], formatted input</c-></c->
<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- p><c- p>(</c-></c-><c- o><c- o>*</c-></c-><c- n><c- n>pf</c-></c-><c- p><c- p>)(</c-></c-><c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-><c- p><c- p>));</c-></c->
<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>basic_ios</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>charT</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>traits</c-></c-><c- o><c- o>>&amp;</c-></c-> <c- p><c- p>(</c-></c-><c- o><c- o>*</c-></c-><c- n><c- n>pf</c-></c-><c- p><c- p>)(</c-></c-><c- n><c- n>basic_ios</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>charT</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>traits</c-></c-><c- o><c- o>>&amp;</c-></c-><c- p><c- p>));</c-></c->
<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>ios_base</c-></c-><c- o><c- o>&amp;</c-></c-> <c- p><c- p>(</c-></c-><c- o><c- o>*</c-></c-><c- n><c- n>pf</c-></c-><c- p><c- p>)(</c-></c-><c- n><c- n>ios_base</c-></c-><c- o><c- o>&amp;</c-></c-><c- p><c- p>));</c-></c->

<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>bool</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>short</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>unsigned</c-></c-> <c- b><c- b>short</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>int</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>unsigned</c-></c-> <c- b><c- b>int</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>unsigned</c-></c-> <c- b><c- b>long</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>long</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>unsigned</c-></c-> <c- b><c- b>long</c-></c-> <c- b><c- b>long</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>n</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>float</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>f</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>double</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>f</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>f</c-></c-><c- p><c- p>);</c-></c->
<ins><c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><i><c- n><c- n>small</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>ext</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>fp</c-></c-></i><c- o><c- o>&amp;</c-></c-> <c- n><c- n>f</c-></c-><c- p><c- p>);</c-></c-></ins>
<ins><c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><i><c- n><c- n>big</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>ext</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>fp</c-></c-></i><c- o><c- o>&amp;</c-></c-> <c- n><c- n>f</c-></c-><c- p><c- p>)</c-></c-> <c- o><c- o>=</c-></c-> <c- k><c- k>delete</c-></c-><c- p><c- p>;</c-></c-></ins>

<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>void</c-></c-><c- o><c- o>*&amp;</c-></c-> <c- n><c- n>p</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>basic_streambuf</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>char_type</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>traits</c-></c-><c- o><c- o>>*</c-></c-> <c- n><c- n>sb</c-></c-><c- p><c- p>);</c-></c->
</code></pre>
   </blockquote>
   <p>Modify 29.7.4.3.2 "Arithmetic extractors" [<strong>istream.formatted.arithmetic</strong>] add the following at the end of the section:</p>
   <blockquote class="ins">
<pre class="highlight"><code class="highlight"><c- n><c- n>basic_istream</c-></c-><c- o><c- o>&amp;</c-></c-> <c- k><c- k>operator</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>(</c-></c-><i><c- n><c- n>small</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>ext</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>fp</c-></c-></i><c- o><c- o>&amp;</c-></c-> <c- n><c- n>val</c-></c-><c- p><c- p>);</c-></c->
</code></pre>
    <p>[ <em>Note</em>: <code class="highlight"><em><c- n>small</c-><c- o>-</c-><c- n>ext</c-><c- o>-</c-><c- n>fp</c-></em></code> is an extended floating-point type whose floating-point conversion rank is less than or equal to the conversion rank of <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> ([istream.general]). -- <em>end note</em> ]</p>
    <p>Let <code class="highlight"><em><c- n>std</c-><c- o>-</c-><c- n>fp</c-></em></code> be a standard floating-point type:</p>
    <ul>
     <li data-md>
      <p>if <code class="highlight"><em><c- n>small</c-><c- o>-</c-><c- n>ext</c-><c- o>-</c-><c- n>fp</c-></em></code> has a floating-point conversion rank that is less than or equal to that of <code class="highlight"><c- b>float</c-></code>, then <code class="highlight"><em><c- n>std</c-><c- o>-</c-><c- n>fp</c-></em></code> is <code class="highlight"><c- b>float</c-></code>,</p>
     <li data-md>
      <p>otherwise, if <code class="highlight"><em><c- n>small</c-><c- o>-</c-><c- n>ext</c-><c- o>-</c-><c- n>fp</c-></em></code> has a floating-point conversion rank that is less than or equal to that of <code class="highlight"><c- b>double</c-></code>, then <code class="highlight"><em><c- n>std</c-><c- o>-</c-><c- n>fp</c-></em></code> is <code class="highlight"><c- b>double</c-></code>,</p>
     <li data-md>
      <p>otherwise, <code class="highlight"><em><c- n>std</c-><c- o>-</c-><c- n>fp</c-></em></code> is <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>.</p>
    </ul>
    <p>The conversion occurs as if performed by the following code fragment (using the same notation as for the preceding code fragment):</p>
<pre class="highlight"><code class="highlight"><c- k><c- k>using</c-></c-> <c- n><c- n>numget</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>num_get</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>charT</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>istreambuf_iterator</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>charT</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>traits</c-></c-><c- o><c- o>>></c-></c-><c- p><c- p>;</c-></c->
<c- n><c- n>iostate</c-></c-> <c- n><c- n>err</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>ios_base</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>goodbit</c-></c-><c- p><c- p>;</c-></c->
<i><c- n><c- n>std</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>fp</c-></c-></i> <c- n><c- n>fval</c-></c-><c- p><c- p>;</c-></c->
<c- n><c- n>use_facet</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>numget</c-></c-><c- o><c- o>></c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>loc</c-></c-><c- p><c- p>).</c-></c-><c- n><c- n>get</c-></c-><c- p><c- p>(</c-></c-><c- o><c- o>*</c-></c-><c- k><c- k>this</c-></c-><c- p><c- p>,</c-></c-> <c- mi><c- mi>0</c-></c-><c- p><c- p>,</c-></c-> <c- o><c- o>*</c-></c-><c- k><c- k>this</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>err</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>fval</c-></c-><c- p><c- p>);</c-></c->
<c- k><c- k>if</c-></c-> <c- p><c- p>(</c-></c-><c- n><c- n>fval</c-></c-> <c- o><c- o>&lt;</c-></c-> <c- o><c- o>-</c-></c-><c- n><c- n>numeric_limits</c-></c-><c- o><c- o>&lt;</c-></c-><i><c- n><c- n>small</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>ext</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>fp</c-></c-></i><c- o><c- o>>::</c-></c-><c- n><c- n>max</c-></c-><c- p><c- p>())</c-></c-> <c- p><c- p>{</c-></c->
  <c- n><c- n>err</c-></c-> <c- o><c- o>|=</c-></c-> <c- n><c- n>ios_base</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>failbit</c-></c-><c- p><c- p>;</c-></c->
  <c- n><c- n>val</c-></c-> <c- o><c- o>=</c-></c-> <c- o><c- o>-</c-></c-><c- n><c- n>numeric_limits</c-></c-><c- o><c- o>&lt;</c-></c-><i><c- n><c- n>small</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>ext</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>fp</c-></c-></i><c- o><c- o>>::</c-></c-><c- n><c- n>max</c-></c-><c- p><c- p>();</c-></c->
<c- p><c- p>}</c-></c-> <c- k><c- k>else</c-></c-> <c- k><c- k>if</c-></c-> <c- p><c- p>(</c-></c-><c- n><c- n>numeric_limits</c-></c-><c- o><c- o>&lt;</c-></c-><i><c- n><c- n>small</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>ext</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>fp</c-></c-></i><c- o><c- o>>::</c-></c-><c- n><c- n>max</c-></c-><c- p><c- p>()</c-></c-> <c- o><c- o>&lt;</c-></c-> <c- n><c- n>fval</c-></c-><c- p><c- p>)</c-></c-> <c- p><c- p>{</c-></c->
  <c- n><c- n>err</c-></c-> <c- o><c- o>|=</c-></c-> <c- n><c- n>ios_base</c-></c-><c- o><c- o>::</c-></c-><c- n><c- n>failbit</c-></c-><c- p><c- p>;</c-></c->
  <c- n><c- n>val</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>numeric_limits</c-></c-><c- o><c- o>&lt;</c-></c-><i><c- n><c- n>small</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>ext</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>fp</c-></c-></i><c- o><c- o>>::</c-></c-><c- n><c- n>max</c-></c-><c- p><c- p>();</c-></c->
<c- p><c- p>}</c-></c-> <c- k><c- k>else</c-></c->
  <c- n><c- n>val</c-></c-> <c- o><c- o>=</c-></c-> <c- k><c- k>static_cast</c-></c-><c- o><c- o>&lt;</c-></c-><i><c- n><c- n>small</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>ext</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>fp</c-></c-></i><c- o><c- o>></c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>fval</c-></c-><c- p><c- p>);</c-></c->
<c- n><c- n>setstate</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>err</c-></c-><c- p><c- p>);</c-></c->
</code></pre>
   </blockquote>
   <h4 class="heading settled" data-level="8.2.4" id="cmath-wording"><span class="secno">8.2.4. </span><span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>cmath</c-><c- o>></c-></code></span><a class="self-link" href="#cmath-wording"></a></h4>
   <p><i>Design: <a href="#cmath">§ 6.5 &lt;cmath></a></i></p>
   <p>Modify 26.8.1 "Header <code class="highlight"><c- o>&lt;</c-><c- n>cmath</c-><c- o>></c-></code> synopsis" [<strong>cmath.syn</strong>] paragraph 2 as follows:</p>
   <blockquote>
     For each set of overloaded functions within <code class="highlight"><c- o>&lt;</c-><c- n>cmath</c-><c- o>></c-></code>, with the exception of <code class="highlight"><c- n>abs</c-></code>, there shall be additional overloads sufficient to ensure: 
    <ul>
     <li data-md>
      <del>1. If any argument of arithmetic type corresponding to a <code class="highlight"><c- b>double</c-></code> parameter has type <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>, then all arguments of arithmetic type (6.7.1) corresponding to <code class="highlight"><c- b>double</c-></code> parameters are effectively cast to <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>.</del>
     <li data-md>
      <del>2. Otherwise, if any argument of arithmetic type corresponding to a <code class="highlight"><c- b>double</c-></code> parameter has type <code class="highlight"><c- b>double</c-></code> or an integer type, then all arguments of arithmetic type corresponding to <code class="highlight"><c- b>double</c-></code> parameters are effectively cast to <code class="highlight"><c- b>double</c-></code>.</del>
     <li data-md>
      <del>3. Otherwise, all arguments of arithmetic type corresponding to <code class="highlight"><c- b>double</c-></code> parameters have type <code class="highlight"><c- b>float</c-></code>.</del>
     <li data-md>
      <ins>1. If any argument corresponding to a <code class="highlight"><c- b>double</c-></code> parameter has floating-point type, then all arguments of arithmetic type ([basic.fundamental]) corresponding to <code class="highlight"><c- b>double</c-></code> parameters are effectively cast to the floating-point type with the greatest floating-point conversion rank ([conv.rank]) and greatest floating-point conversion subrank among the types of such floating-point arguments. If two such floating-point arguments have types whose conversion rank is unordered, the program is ill-formed.</ins>
     <li data-md>
      <ins>2. Otherwise, all arguments of arithmetic type corresponding to <code class="highlight"><c- b>double</c-></code> parameters are effectively cast to <code class="highlight"><c- b>double</c-></code>.</ins>
    </ul>
    <p>[ <em>Note</em>: <code class="highlight"><c- n>abs</c-></code> is exempted from these rules in order to stay compatible with C. -- <em>end note</em> ]</p>
   </blockquote>
   <p>Modify section 26.8.2 "Absolute values" [<strong>c.math.abs</strong>] as follows:</p>
   <blockquote>
    <div class="numbered"> [ <em>Note</em>: The headers <code class="highlight"><c- o>&lt;</c-><c- n>cstdlib</c-><c- o>></c-></code> and <code class="highlight"><c- o>&lt;</c-><c- n>cmath</c-><c- o>></c-></code> declare the functions described in this subclause. — <em>end note</em> ] </div>
<pre class="highlight"><code class="highlight"><c- b><c- b>int</c-></c-> <c- nf><c- nf>abs</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>int</c-></c-> <c- n><c- n>j</c-></c-><c- p><c- p>);</c-></c->
<c- b><c- b>long</c-></c-> <c- b><c- b>int</c-></c-> <c- n><c- n>abs</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>int</c-></c-> <c- n><c- n>j</c-></c-><c- p><c- p>);</c-></c->
<c- b><c- b>long</c-></c-> <c- b><c- b>long</c-></c-> <c- b><c- b>int</c-></c-> <c- n><c- n>abs</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>long</c-></c-> <c- b><c- b>int</c-></c-> <c- n><c- n>j</c-></c-><c- p><c- p>);</c-></c->
<del><c- b><c- b>float</c-></c-> <c- nf><c- nf>abs</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>float</c-></c-> <c- n><c- n>j</c-></c-><c- p><c- p>);</c-></c->
<c- b><c- b>double</c-></c-> <c- nf><c- nf>abs</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>double</c-></c-> <c- n><c- n>j</c-></c-><c- p><c- p>);</c-></c->
<c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>abs</c-></c-><c- p><c- p>(</c-></c-><c- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-> <c- n><c- n>j</c-></c-><c- p><c- p>);</c-></c-></del>
</code></pre>
    <div class="numbered">
      <em>Effects</em>: The <code class="highlight"><c- n>abs</c-></code> functions 
     <ins>that take integer arguments</ins>
      have the semantics specified in the C standard library for the functions <code class="highlight"><c- n>abs</c-></code>, <code class="highlight"><c- n>labs</c-></code>, 
     <ins>and</ins>
      <code class="highlight"><c- n>llabs</c-></code>
     <del>, <code class="highlight"><c- n>fabsf</c-></code>, <code class="highlight"><c- n>fabs</c-></code>, and <code class="highlight"><c- n>fabsl</c-></code></del>
     . 
    </div>
    <div class="numbered"> <em>Remarks</em>: If <code class="highlight"><c- n>abs</c-><c- p>()</c-></code> is called with an argument of type <code class="highlight"><c- n>X</c-></code> for which <code class="highlight"><c- n>is_unsigned_v</c-><c- o>&lt;</c-><c- n>X</c-><c- o>></c-></code> is <code class="highlight">true</code> and if <code class="highlight"><c- n>X</c-></code> cannot be converted to <code class="highlight"><c- b>int</c-></code> by integral promotion, the program is ill-formed.  [ <em>Note</em>: Arguments that can be promoted to <code class="highlight"><c- b>int</c-></code> are permitted for compatibility with C. — <em>end note</em> ] </div>
<pre class="highlight"><code class="highlight"><ins><em><c- n><c- n>floating</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>point</c-></c-></em> <c- n><c- n>abs</c-></c-><c- p><c- p>(</c-></c-><em><c- n><c- n>floating</c-></c-><c- o><c- o>-</c-></c-><c- n><c- n>point</c-></c-></em> <c- n><c- n>x</c-></c-><c- p><c- p>);</c-></c-></ins>
</code></pre>
    <div class="numbered">
     <ins><em>Returns</em>: The absolute value of <code class="highlight"><c- n>x</c-></code>.</ins>
    </div>
    <div class="numbered">
     <ins><em>Remarks</em>: The implementation provides overloads for all floating-point types as the type of parameter <code class="highlight"><c- n>x</c-></code>, with the same floating-point type as the return type.</ins>
    </div>
    <p>See also: ISO C 7.12.7.2, 7.22.6.1</p>
   </blockquote>
   <h4 class="heading settled" data-level="8.2.5" id="complex-wording"><span class="secno">8.2.5. </span><span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>complex</c-><c- o>></c-></code></span><a class="self-link" href="#complex-wording"></a></h4>
   <p><i>Design: <a href="#complex">§ 6.6 &lt;complex></a></i></p>
   <p>Modify 26.4 "Complex numbers" [<strong>complex.numbers</strong>] paragraph 2 as follows:</p>
   <blockquote>
     The effect of instantiating the template <code class="highlight"><c- n>complex</c-></code> for any type 
    <del>other than <code class="highlight"><c- b>float</c-></code>, <code class="highlight"><c- b>double</c-></code>, or <code class="highlight"><c- b>long</c-> <c- b>double</c-></code></del>
    <ins>that is not a floating-point type</ins>
     is unspecified. The specializations 
    <del><code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- b>float</c-><c- o>></c-></code>, <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- b>double</c-><c- o>></c-></code>, and <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- b>long</c-> <c- b>double</c-><c- o>></c-></code></del>
    <ins>of <code class="highlight"><c- n>complex</c-></code> for floating-point types</ins>
     are literal types ([basic.types]). 
   </blockquote>
   <p>Delete the explicit specializations from 26.4.1 "Header <code class="highlight"><c- o>&lt;</c-><c- n>complex</c-><c- o>></c-></code> synopsis" [<strong>complex.syn</strong>]:</p>
   <blockquote>
<pre class="highlight"><code class="highlight"><c- k><c- k>namespace</c-></c-> <c- n><c- n>std</c-></c-> <c- p><c- p>{</c-></c->
  <c- c1><c- c1>// </c-></c-><em><c- c1><c- c1>26.4.2, class template</c-></c-></em><c- c1><c- c1> complex</c-></c->
  <c- k><c- k>template</c-></c-><class t> <c- k><c- k>class</c-></c-> <c- nc><c- nc>complex</c-></c-><c- p><c- p>;</c-></c->

<del>  <c- c1><c- c1>// </c-></c-><em><c- c1><c- c1>26.4.3, specializations</c-></c-></em>
  <c- k><c- k>template</c-></c-><c- o><c- o>&lt;></c-></c-> <c- k><c- k>class</c-></c-> <c- nc><c- nc>complex</c-></c-><float><c- p><c- p>;</c-></c->
  <c- k><c- k>template</c-></c-><c- o><c- o>&lt;></c-></c-> <c- k><c- k>class</c-></c-> <c- nc><c- nc>complex</c-></c-><double><c- p><c- p>;</c-></c->
  <c- k><c- k>template</c-></c-><c- o><c- o>&lt;></c-></c-> <c- k><c- k>class</c-></c-> <c- nc><c- nc>complex</c-></c-><long double><c- p><c- p>;</c-></c-></long></double></float></del>

  <c- c1><c- c1>// ...</c-></c->
</class></code></pre>
   </blockquote>
   <p>In 26.4.2 "Class template <code class="highlight"><c- n>complex</c-></code>" [<strong>complex</strong>], modify the synopsis of the constructors as follows:</p>
   <blockquote>
<pre class="highlight"><code class="highlight"><c- k><c- k>constexpr</c-></c-> <c- nf><c- nf>complex</c-></c-><c- p><c- p>(</c-></c-><c- k><c- k>const</c-></c-> <c- n><c- n>T</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>re</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>T</c-></c-><c- p><c- p>(),</c-></c-> <c- k><c- k>const</c-></c-> <c- n><c- n>T</c-></c-><c- o><c- o>&amp;</c-></c-> <c- n><c- n>im</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>T</c-></c-><c- p><c- p>());</c-></c->
<c- k><c- k>constexpr</c-></c-> <c- nf><c- nf>complex</c-></c-><c- p><c- p>(</c-></c-><c- k><c- k>const</c-></c-> <c- n><c- n>complex</c-></c-><c- o><c- o>&amp;</c-></c-><c- p><c- p>)</c-></c-> <ins><c- o><c- o>=</c-></c-> <c- k><c- k>default</c-></c-></ins><c- p><c- p>;</c-></c->
<c- k><c- k>template</c-></c-><c- o><c- o>&lt;</c-></c-><c- k><c- k>class</c-></c-> <c- nc><c- nc>X</c-></c-><c- o><c- o>></c-></c-> <c- k><c- k>constexpr</c-></c-> <ins><c- k><c- k>explicit</c-></c-><c- p><c- p>(</c-></c-><em><c- n><c- n>see</c-></c-> <c- n><c- n>below</c-></c-></em><c- p><c- p>)</c-></c-></ins> <c- n><c- n>complex</c-></c-><c- p><c- p>(</c-></c-><c- k><c- k>const</c-></c-> <c- n><c- n>complex</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>X</c-></c-><c- o><c- o>>&amp;</c-></c-><c- p><c- p>);</c-></c->
</code></pre>
   </blockquote>
   <p>Remove section 26.4.3 "Specializations" [<strong>complex.special</strong>] in its entirety.</p>
   <p>In 26.4.4 "Member functions" [<strong>complex.members</strong>], add the following after paragraph 1:</p>
   <blockquote class="ins">
<pre class="highlight"><code class="highlight"><c- k><c- k>template</c-></c-><c- o><c- o>&lt;</c-></c-><c- k><c- k>class</c-></c-> <c- nc><c- nc>X</c-></c-><c- o><c- o>></c-></c-> <c- k><c- k>constexpr</c-></c-> <c- k><c- k>explicit</c-></c-><c- p><c- p>(</c-></c-><em><c- n><c- n>see</c-></c-> <c- n><c- n>below</c-></c-></em><c- p><c- p>)</c-></c-> <c- n><c- n>complex</c-></c-><c- p><c- p>(</c-></c-><c- k><c- k>const</c-></c-> <c- n><c- n>complex</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>X</c-></c-><c- o><c- o>>&amp;</c-></c-> <c- n><c- n>other</c-></c-><c- p><c- p>);</c-></c-></code></pre>
    <p><em>Postconditions</em>: <code class="highlight"><c- n>real</c-><c- p>()</c-> <c- o>==</c-> <c- n>other</c-><c- p>.</c-><c- n>real</c-><c- p>()</c-></code> and <code class="highlight"><c- n>imag</c-><c- p>()</c-> <c- o>==</c-> <c- n>other</c-><c- p>.</c-><c- n>imag</c-><c- p>()</c-></code>.</p>
    <p><em>Remarks</em>: The expression inside <code class="highlight"><c- k>explicit</c-></code> evaluates to <code class="highlight">false</code> if and only if the floating-point conversion rank of <code class="highlight"><c- n>T</c-></code> is greater than or equal to the floating-point conversion rank of <code class="highlight"><c- n>X</c-></code>.</p>
   </blockquote>
   <p>Modify 26.4.9 "Additional overloads" [<strong>cmplx.over</strong>] paragraphs 2 and 3 as follows:</p>
   <blockquote>
     The additional overloads shall be sufficient to ensure: 
    <ul>
     <li data-md>
      <del>If the argument has type <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>, then it is effectively cast to <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- b>long</c-> <c- b>double</c-><c- o>></c-></code>.</del>
     <li data-md>
      <del>Otherwise, if the argument has type <code class="highlight"><c- b>double</c-></code> or an integer type, then it is effectively cast to <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- b>double</c-><c- o>></c-></code>.</del>
     <li data-md>
      <del>Otherwise, if the argument has type <code class="highlight"><c- b>float</c-></code>, then it is effectively cast to <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- b>float</c-><c- o>></c-></code>.</del>
     <li data-md>
      <ins>If the argument has a floating-point type <code class="highlight"><c- n>T</c-></code>, then it is effectively cast to <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code>.</ins>
     <li data-md>
      <ins>Otherwise, if the argument has integer type, then it is effectively cast to <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- b>double</c-><c- o>></c-></code>.</ins>
    </ul>
    <p>Function template <code class="highlight"><c- n>pow</c-></code> shall have additional overloads sufficient to ensure, for a call with at least one argument of type <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code>:</p>
    <ul>
     <li data-md>
      <del>If either argument has type <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- b>long</c-> <c- b>double</c-><c- o>></c-></code> or type <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>, then both arguments are effectively cast to <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- b>long</c-> <c- b>double</c-><c- o>></c-></code>.</del>
     <li data-md>
      <del>Otherwise, if either argument has type <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- b>double</c-><c- o>></c-></code>, <code class="highlight"><c- b>double</c-></code>, or an integer type, then both arguments are effectively cast to <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- b>double</c-><c- o>></c-></code>.</del>
     <li data-md>
      <del>Otherwise, if either argument has type <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- b>float</c-><c- o>></c-></code> or <code class="highlight"><c- b>float</c-></code>, then both arguments are effectively cast to <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- b>float</c-><c- o>></c-></code>.</del>
     <li data-md>
      <ins>If one argument is of type <code class="highlight"><c- n>T1</c-></code> or <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- n>T1</c-><c- o>></c-></code> and the other argument is of type <code class="highlight"><c- n>T2</c-></code> or <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- n>T2</c-><c- o>></c-></code> where <code class="highlight"><c- n>T1</c-></code> and <code class="highlight"><c- n>T2</c-></code> are both floating-point types:</ins>
      <ul>
       <li data-md>
        <ins>If the floating-point conversion ranks ([conv.rank]) of <code class="highlight"><c- n>T1</c-></code> and <code class="highlight"><c- n>T2</c-></code> are unordered, the program is ill-formed.</ins>
       <li data-md>
        <ins>Otherwise, if <code class="highlight"><c- n>T1</c-></code> has greater floating-point conversion rank than <code class="highlight"><c- n>T2</c-></code>, or if <code class="highlight"><c- n>T1</c-></code> and <code class="highlight"><c- n>T2</c-></code> have equal conversion ranks and <code class="highlight"><c- n>T1</c-></code> has greater floating-point conversion subrank ([conv.rank]) than <code class="highlight"><c- n>T2</c-></code>, then both arguments are effectively cast to <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- n>T1</c-><c- o>></c-></code>.</ins>
       <li data-md>
        <ins>Otherwise, both arguments are effectively cast to <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- n>T2</c-><c- o>></c-></code>.</ins>
      </ul>
     <li data-md>
      <ins>Otherwise, if the other argument has integer type, it is effectively cast to <code class="highlight"><c- n>complex</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code>.</ins>
    </ul>
   </blockquote>
   <h4 class="heading settled" data-level="8.2.6" id="atomic-wording"><span class="secno">8.2.6. </span><span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>atomic</c-><c- o>></c-></code></span><a class="self-link" href="#atomic-wording"></a></h4>
   <p><i>Design: <a href="#atomic">§ 6.7 &lt;atomic></a></i></p>
   <p>Modify 31.8.3 "Specializations for floating-point types" [<strong>atomics.types.float</strong>] paragraph 1 as follows:</p>
   <blockquote>
     There are specializations of the <code class="highlight"><c- n>atomic</c-></code> class template for the floating-point types <code class="highlight"><c- b>float</c-></code>, <code class="highlight"><c- b>double</c-></code>, and <code class="highlight"><c- b>long</c-> <c- b>double</c-></code>
    <ins>, and any other floating-point types needed by the type aliases in the header <code class="highlight"><c- o>&lt;</c-><c- n>stdfloat</c-><c- o>></c-></code></ins>
    . For each such type <code class="highlight"><em><c- n>floating</c-><c- o>-</c-><c- n>point</c-></em></code>, the specialization <code class="highlight"><c- n>atomic</c-><c- o>&lt;</c-><em><c- n>floating</c-><c- o>-</c-><c- n>point</c-></em><c- o>></c-></code> provides additional atomic operations appropriate to floating-point types. 
   </blockquote>
   <h4 class="heading settled" data-level="8.2.7" id="test-macros-wording"><span class="secno">8.2.7. </span><span class="content">Feature test macros</span><a class="self-link" href="#test-macros-wording"></a></h4>
   <p>Add the following feature test macros to [<strong>version.syn</strong>].  These are different from all the other library feature test macros because they are conditionally defined, so they don’t fit neatly into the existing table.  Some guidance is needed on how best to word this.</p>
   <ul>
    <li data-md>
     <p><code class="highlight"><c- n>__cpp_lib_float16_t</c-></code>: if <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float16_t</c-></code> is available, also in <code class="highlight"><c- o>&lt;</c-><c- n>stdfloat</c-><c- o>></c-></code></p>
    <li data-md>
     <p><code class="highlight"><c- n>__cpp_lib_float32_t</c-></code>: if <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float32_t</c-></code> is available, also in <code class="highlight"><c- o>&lt;</c-><c- n>stdfloat</c-><c- o>></c-></code></p>
    <li data-md>
     <p><code class="highlight"><c- n>__cpp_lib_float64_t</c-></code>: if <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code> is available, also in <code class="highlight"><c- o>&lt;</c-><c- n>stdfloat</c-><c- o>></c-></code></p>
    <li data-md>
     <p><code class="highlight"><c- n>__cpp_lib_float128_t</c-></code>: if <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float128_t</c-></code> is available, also in <code class="highlight"><c- o>&lt;</c-><c- n>stdfloat</c-><c- o>></c-></code></p>
    <li data-md>
     <p><code class="highlight"><c- n>__cpp_lib_bfloat16_t</c-></code>: if <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>bfloat16_t</c-></code> is available, also in <code class="highlight"><c- o>&lt;</c-><c- n>stdfloat</c-><c- o>></c-></code></p>
   </ul>
  </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-bfloat16">[BFLOAT16]
   <dd><a href="https://en.wikipedia.org/wiki/Bfloat16_floating-point_format"><cite>bfloat16 floating-point format</cite></a>. URL: <a href="https://en.wikipedia.org/wiki/Bfloat16_floating-point_format">https://en.wikipedia.org/wiki/Bfloat16_floating-point_format</a>
   <dt id="biblio-eisel-lemire">[Eisel-Lemire]
   <dd>Daniel Lemire. <a href="https://arxiv.org/abs/2101.11408"><cite>Number Parsing at a Gigabyte per Second</cite></a>. URL: <a href="https://arxiv.org/abs/2101.11408">https://arxiv.org/abs/2101.11408</a>
   <dt id="biblio-ieee-754-2008">[IEEE-754-2008]
   <dd><a href="http://ieeexplore.ieee.org/servlet/opac?punumber=4610933"><cite>IEEE Standard for Floating-Point Arithmetic</cite></a>. 29 August 2008. URL: <a href="http://ieeexplore.ieee.org/servlet/opac?punumber=4610933">http://ieeexplore.ieee.org/servlet/opac?punumber=4610933</a>
   <dt id="biblio-libquadmath">[LIBQUADMATH]
   <dd><a href="https://gcc.gnu.org/onlinedocs/gcc-6.5.0/libquadmath.pdf"><cite>The GCC Quad-Precision Math Library</cite></a>. URL: <a href="https://gcc.gnu.org/onlinedocs/gcc-6.5.0/libquadmath.pdf">https://gcc.gnu.org/onlinedocs/gcc-6.5.0/libquadmath.pdf</a>
   <dt id="biblio-n1703">[N1703]
   <dd>Paul A. Bristow; Christopher Kormanyos; John Maddock. <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1703.pdf"><cite>Floating-Point Typedefs Having Specified Widths</cite></a>. URL: <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1703.pdf">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1703.pdf</a>
   <dt id="biblio-n3387">[N3387]
   <dd>Jens Maurer. <a href="https://wg21.link/n3387"><cite>Overload resolution tiebreakers for integer types</cite></a>. 12 September 2012. URL: <a href="https://wg21.link/n3387">https://wg21.link/n3387</a>
   <dt id="biblio-p0192">[P0192]
   <dd>Michał Dominiak; et al. <a href="https://wg21.link/P0192"><cite>`short float` and fixed-size floating point types</cite></a>. URL: <a href="https://wg21.link/P0192">https://wg21.link/P0192</a>
   <dt id="biblio-p0870">[P0870]
   <dd>Giuseppe D'Angelo. <a href="https://wg21.link/p0870"><cite>A proposal for a type trait to detect narrowing conversions</cite></a>. URL: <a href="https://wg21.link/p0870">https://wg21.link/p0870</a>
   <dt id="biblio-p1818">[P1818]
   <dd>Lawrence Crowl. <a href="https://wg21.link/P1818"><cite>Narrowing and Widening Conversions</cite></a>. URL: <a href="https://wg21.link/P1818">https://wg21.link/P1818</a>
   <dt id="biblio-ryu">[Ryu]
   <dd><a href="https://github.com/ulfjack/ryu"><cite>Ryu algorithm</cite></a>. URL: <a href="https://github.com/ulfjack/ryu">https://github.com/ulfjack/ryu</a>
   <dt id="biblio-wg14-n2601">[WG14-N2601]
   <dd><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2601.pdf"><cite>Annex X (normative): IEC 60559 interchange and extended types</cite></a>. URL: <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2601.pdf">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2601.pdf</a>
  </dl>
  <h2 class="no-num no-ref heading settled" id="issues-index"><span class="content">Issues Index</span><a class="self-link" href="#issues-index"></a></h2>
  <div style="counter-reset:issue">
   <div class="issue"> Should there be a feature test macro to indicate that the implementation supports at least one extended floating-point type? <a class="issue-return" href="#issue-6daed810" title="Jump to section">↵</a></div>
   <div class="issue"> Should literal suffixes be defined for complex numbers of extended floating-point types with standard names, similar to the non-complex <a href="#literals">suffixes</a>? <a class="issue-return" href="#issue-c91d4ff8" title="Jump to section">↵</a></div>
   <div class="issue"> How should feature test macros be handled for this feature? <a class="issue-return" href="#issue-50e4e46f" title="Jump to section">↵</a></div>
  </div>