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

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

	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;

		/* Colors */
		color: black;
		background: white 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-width: .65rem .7rem .6rem;
		border-radius: .4rem;
		background: #1a5e9a;
		color: white;
		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;
		border-color: #c00;
	}

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

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

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

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

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

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

			background: white;
			box-shadow: 0 0 2px;
			border: none;
			border-top-right-radius: 1.33em;
			background: white;
		}
		#toc-nav > #toc-jump {
			padding-bottom: 2em;
			margin-bottom: -1.9em;
		}

		#toc-nav > a:hover,
		#toc-nav > a:focus {
			background: #f8f8f8;
		}
		#toc-nav > a:not(:hover):not(:focus) {
			color: #707070;
		}

		/* 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-toggle-inline {
			vertical-align: 0.05em;
			font-size: 80%;
			color: gray;
			color: hsla(203,20%,40%,.7);
			border-style: none;
			background: transparent;
			position: relative;
		}
		#toc-toggle-inline:hover:not(:active),
		#toc-toggle-inline:focus:not(:active) {
			text-shadow: 1px 1px silver;
			top: -1px;
			left: -1px;
		}

		#toc-nav :active {
			color: #C00;
		}
	}

/** 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);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) 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);
		}
		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);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) 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);
		}

		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;
		background: transparent;
	}

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

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

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

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

	:not(.head) > hr {
		font-size: 1.5em;
		text-align: center;
		margin: 1em auto;
		height: auto;
		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;
	}

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

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

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


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

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

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

	del { color: red;  text-decoration: line-through; }
	ins { color: #080; text-decoration: underline;    }

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

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

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

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

	pre, code, samp {
		font-family: Menlo, Consolas, "DejaVu Sans Mono", Monaco, monospace;
		font-size: .9em;
		page-break-inside: avoid;
		hyphens: none;
		text-transform: none;
	}
	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;
		text-decoration: none;
		border-bottom: 1px solid #707070;
		/* Need a bit of extending for it to look okay */
		padding: 0 1px 0;
		margin: 0 -1px 0;
	}
	a:visited {
		border-bottom-color: #BBB;
	}

	/* Use distinguishing colors when user is interacting with the link */
	a[href]:focus,
	a[href]:hover {
		background: #f8f8f8;
		background: rgba(75%, 75%, 75%, .25);
		border-bottom-width: 3px;
		margin-bottom: -2px;
	}
	a[href]:active {
		color: #C00;
		border-color: #C00;
	}

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

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

	img {
		border-style: none;
	}

	/* 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;
	}
	.figure pre, .sidefigure pre, figure pre {
		text-align: left;
		display: table;
		margin: 1em auto;
	}
	.figure table, figure table {
		margin: auto;
	}
	@media screen and (min-width: 20em) {
		.sidefigure {
			float: right;
			width: 50%;
			margin: 0 0 0.5em 0.5em
		}
	}
	.caption, figcaption, caption {
		font-style: italic;
		font-size: 90%;
	}
	.caption::before, figcaption::before, figcaption > .marker {
		font-weight: bold;
	}
	.caption, figcaption {
		counter-increment: figure;
	}

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

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

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

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

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

	blockquote {
		border-color: silver;
	}

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

	.issue {
		border-color: #E05252;
		background: #FBE9E9;
		counter-increment: issue;
		overflow: auto;
	}
	.issue::before, .issue > .marker {
		text-transform: uppercase;
		color: #AE1E1E;
		padding-right: 1em;
		text-transform: uppercase;
	}
	/* 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;
		background: #FCFAEE;
		counter-increment: example;
		overflow: auto;
		clear: both;
	}
	.example::before, .example > .marker {
		text-transform: uppercase;
		color: #827017;
		min-width: 7.5em;
		display: block;
	}
	/* 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;
		background: #E9FBE9;
		overflow: auto;
	}

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

	details.note > summary {
		display: block;
		color: hsl(120, 70%, 30%);
	}
	details.note[open] > summary {
		border-bottom: 1px silver solid;
	}

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

	.assertion {
		border-color: #AAA;
		background: #EEE;
	}

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

	.advisement {
		border-color: orange;
		border-style: none solid;
		background: #FFEECC;
	}
	strong.advisement {
		display: block;
		text-align: center;
	}
	.advisement > .marker {
		color: #B35F00;
	}

/** 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: #fdd;
		color: red;
		font-weight: bold;
		padding: .75em 1em;
		border: thick red;
		border-style: solid;
		border-radius: 1em;
	}
	.annoying-warning :last-child {
		margin-bottom: 0;
	}

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

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

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

	.def {
		padding: .5em 1em;
		background: #DEF;
		margin: 1.2em 0;
		border-left: 0.5em solid #8CCBF2;
	}

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

	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-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;
		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;
		text-align: center;
	}

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

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


/*
Alternate table alignment rules

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

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

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

Possible extra rowspan handling

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

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

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


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

	.toc a {
		/* More spacing; use padding to make it part of the click target. */
		padding-top: 0.1rem;
		/* Larger, more consistently-sized click target */
		display: block;
		/* Reverse color scheme */
		color: black;
		border-color: #3980B5;
		border-bottom-width: 3px !important;
		margin-bottom: 0px !important;
	}
	.toc a:visited {
		border-color: #054572;
	}
	.toc a:not(:focus):not(:hover) {
		/* Allow colors to cascade through from link styling */
		border-bottom-color: transparent;
	}

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

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

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

		/* Section numbers in a column of their own */
		.toc .secno {
			float: left;
			width: 4rem;
			white-space: nowrap;
		}

		.toc li {
			clear: both;
		}

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

		/* Tighten up indentation in narrow ToCs */
		@media (max-width: 30em) {
			:not(li) > .toc              { margin-left:  4rem; }
			.toc .secno                  { margin-left: -4rem; }
			.toc > li li li              { margin-left:  1rem; }
			.toc > li li li .secno       { margin-left: -5rem; }
			.toc > li li li li .secno    { margin-left: -6rem; }
			.toc > li li li li li .secno { margin-left: -7rem; }
		}
	/* } */

	@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 {
			background: rgba(75%, 75%, 75%, .25);
			border-bottom: 3px solid #054572;
			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 {
			white-space: nowrap;
			color: transparent; }
		ul.index li a:hover + span,
		ul.index li a:focus + span {
			color: #707070;
		}
	}

/** 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]) {
		background: #f7f8f9;
	}

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

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

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

/******************************************************************************/
/*                                    Legacy                                  */
/******************************************************************************/

	/* This rule is inherited from past style sheets. No idea what it's for. */
	.hide { display: none }



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

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

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

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

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

    del { background: #fcc; color: #000; text-decoration: line-through; }
    ins { background: #cfc; color: #000; }
    blockquote .highlight:not(.idl) { background: initial; margin: initial; padding: 0.5em }
    blockquote ul { background: inherit; }
    blockquote code.highlight:not(.idl) { padding: initial; }
    blockquote c-[a] { color: inherit; } /* Keyword.Declaration */
    blockquote c-[b] { color: inherit; } /* Keyword.Type */
    blockquote c-[c] { color: inherit; } /* Comment */
    blockquote c-[d] { color: inherit; } /* Comment.Multiline */
    blockquote c-[e] { color: inherit; } /* Name.Attribute */
    blockquote c-[f] { color: inherit; } /* Name.Tag */
    blockquote c-[g] { color: inherit; } /* Name.Variable */
    blockquote c-[k] { color: inherit; } /* Keyword */
    blockquote c-[l] { color: inherit; } /* Literal */
    blockquote c-[m] { color: inherit; } /* Literal.Number */
    blockquote c-[n] { color: inherit; } /* Name */
    blockquote c-[o] { color: inherit; } /* Operator */
    blockquote c-[p] { color: inherit; } /* Punctuation */
    blockquote c-[s] { color: inherit; } /* Literal.String */
    blockquote c-[t] { color: inherit; } /* Literal.String.Single */
    blockquote c-[u] { color: inherit; } /* Literal.String.Double */
    blockquote c-[cp] { color: inherit; } /* Comment.Preproc */
    blockquote c-[c1] { color: inherit; } /* Comment.Single */
    blockquote c-[cs] { color: inherit; } /* Comment.Special */
    blockquote c-[kc] { color: inherit; } /* Keyword.Constant */
    blockquote c-[kn] { color: inherit; } /* Keyword.Namespace */
    blockquote c-[kp] { color: inherit; } /* Keyword.Pseudo */
    blockquote c-[kr] { color: inherit; } /* Keyword.Reserved */
    blockquote c-[ld] { color: inherit; } /* Literal.Date */
    blockquote c-[nc] { color: inherit; } /* Name.Class */
    blockquote c-[no] { color: inherit; } /* Name.Constant */
    blockquote c-[nd] { color: inherit; } /* Name.Decorator */
    blockquote c-[ni] { color: inherit; } /* Name.Entity */
    blockquote c-[ne] { color: inherit; } /* Name.Exception */
    blockquote c-[nf] { color: inherit; } /* Name.Function */
    blockquote c-[nl] { color: inherit; } /* Name.Label */
    blockquote c-[nn] { color: inherit; } /* Name.Namespace */
    blockquote c-[py] { color: inherit; } /* Name.Property */
    blockquote c-[ow] { color: inherit; } /* Operator.Word */
    blockquote c-[mb] { color: inherit; } /* Literal.Number.Bin */
    blockquote c-[mf] { color: inherit; } /* Literal.Number.Float */
    blockquote c-[mh] { color: inherit; } /* Literal.Number.Hex */
    blockquote c-[mi] { color: inherit; } /* Literal.Number.Integer */
    blockquote c-[mo] { color: inherit; } /* Literal.Number.Oct */
    blockquote c-[sb] { color: inherit; } /* Literal.String.Backtick */
    blockquote c-[sc] { color: inherit; } /* Literal.String.Char */
    blockquote c-[sd] { color: inherit; } /* Literal.String.Doc */
    blockquote c-[se] { color: inherit; } /* Literal.String.Escape */
    blockquote c-[sh] { color: inherit; } /* Literal.String.Heredoc */
    blockquote c-[si] { color: inherit; } /* Literal.String.Interpol */
    blockquote c-[sx] { color: inherit; } /* Literal.String.Other */
    blockquote c-[sr] { color: inherit; } /* Literal.String.Regex */
    blockquote c-[ss] { color: inherit; } /* Literal.String.Symbol */
    blockquote c-[vc] { color: inherit; } /* Name.Variable.Class */
    blockquote c-[vg] { color: inherit; } /* Name.Variable.Global */
    blockquote c-[vi] { color: inherit; } /* Name.Variable.Instance */
    blockquote c-[il] { color: inherit; } /* Literal.Number.Integer.Long */
  </style>
  <meta content="Bikeshed version 6a4c097ae8b731ee02752a258e8ac5ffbb752299" name="generator">
  <link href="https://wg21.link/P1467" 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-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-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-selflinks */

.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: gray;
    color: white;
    font-style: normal;
    transition: opacity .2s, background-color .2s, color .2s;
}
dfn:hover > a.self-link {
    opacity: 1;
}
dfn > a.self-link:hover {
    color: black;
}

a.self-link::before            { content: "¶"; }
.heading > a.self-link::before { content: "§"; }
dfn > a.self-link::before      { content: "#"; }</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-autolinks */

.css.css, .property.property, .descriptor.descriptor {
    color: #005a9c;
    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-syntax-highlighting */

.highlight:not(.idl) { background: hsl(24, 20%, 95%); }
code.highlight { padding: .1em; border-radius: .3em; }
pre.highlight, pre > code.highlight { display: block; padding: 1em; margin: .5em 0; overflow: auto; border-radius: 0; }
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>
 <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">P1467R3<br>Extended floating-point types</h1>
   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Published Proposal, <time class="dt-updated" datetime="2020-01-10">2020-01-10</time></span></h2>
   <div data-fill-with="spec-metadata">
    <dl>
     <dt>This version:
     <dd><a class="u-url" href="https://wg21.link/P1467">https://wg21.link/P1467</a>
     <dt>Issue Tracking:
     <dd><a href="#issues-index">Inline In Spec</a>
     <dt>Authors:
     <dd>
      <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>
      <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-Prague)</span></a>
     </ol>
    <li><a href="#motivation"><span class="secno">3</span> <span class="content">Motivation</span></a>
    <li><a href="#proposal"><span class="secno">4</span> <span class="content">Proposal summary</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>
        <li><a href="#extended-wording"><span class="secno">5.2.2</span> <span class="content">Wording</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>
        <li><a href="#rank-wording"><span class="secno">5.3.2</span> <span class="content">Wording</span></a>
       </ol>
      <li>
       <a href="#promotion"><span class="secno">5.4</span> <span class="content">Promotion</span></a>
       <ol class="toc">
        <li><a href="#promotion-reason"><span class="secno">5.4.1</span> <span class="content">Reasoning</span></a>
        <li><a href="#promotion-wording"><span class="secno">5.4.2</span> <span class="content">Wording</span></a>
       </ol>
      <li>
       <a href="#implicit"><span class="secno">5.5</span> <span class="content">Implicit conversions</span></a>
       <ol class="toc">
        <li><a href="#implicit-example"><span class="secno">5.5.1</span> <span class="content">Example</span></a>
        <li><a href="#implicit-wording"><span class="secno">5.5.2</span> <span class="content">Wording</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>
        <li><a href="#arithmetic-wording"><span class="secno">5.6.2</span> <span class="content">Wording</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-reason"><span class="secno">5.7.1</span> <span class="content">Same representation</span></a>
        <li><a href="#narrow-constant"><span class="secno">5.7.2</span> <span class="content">Constant values</span></a>
        <li><a href="#narrow-wording"><span class="secno">5.7.3</span> <span class="content">Wording</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-reason"><span class="secno">5.8.1</span> <span class="content">Reasoning</span></a>
        <li><a href="#overload-example"><span class="secno">5.8.2</span> <span class="content">Examples</span></a>
        <li><a href="#overload-wording"><span class="secno">5.8.3</span> <span class="content">Wording</span></a>
        <li><a href="#overload-alternate"><span class="secno">5.8.4</span> <span class="content">Alternate proposal</span></a>
       </ol>
      <li>
       <a href="#pointer"><span class="secno">5.9</span> <span class="content">Pointer conversions</span></a>
       <ol class="toc">
        <li><a href="#pointer-reason"><span class="secno">5.9.1</span> <span class="content">Reasoning</span></a>
        <li><a href="#pointer-wording"><span class="secno">5.9.2</span> <span class="content">Wording</span></a>
       </ol>
      <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>
       <ol class="toc">
        <li><a href="#charconv-wording"><span class="secno">6.2.1</span> <span class="content">Wording</span></a>
       </ol>
      <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>
       <ol class="toc">
        <li><a href="#format-wording"><span class="secno">6.3.1</span> <span class="content">Wording</span></a>
       </ol>
      <li>
       <a href="#cmath"><span class="secno">6.4</span> <span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>cmath</c-><c- o>></c-></code></span></a>
       <ol class="toc">
        <li><a href="#cmath-wording"><span class="secno">6.4.1</span> <span class="content">Wording</span></a>
       </ol>
      <li>
       <a href="#complex"><span class="secno">6.5</span> <span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>complex</c-><c- o>></c-></code></span></a>
       <ol class="toc">
        <li><a href="#complex-wording"><span class="secno">6.5.1</span> <span class="content">Wording</span></a>
       </ol>
      <li>
       <a href="#atomic"><span class="secno">6.6</span> <span class="content"><code class="highlight"><c- o>&lt;</c-><c- n>atomic</c-><c- o>></c-></code></span></a>
       <ol class="toc">
        <li><a href="#atomic-wording"><span class="secno">6.6.1</span> <span class="content">Wording</span></a>
       </ol>
      <li><a href="#lib-test-macro"><span class="secno">6.7</span> <span class="content">Feature test macro</span></a>
     </ol>
    <li>
     <a href="#references"><span class="secno"></span> <span class="content">References</span></a>
     <ol class="toc">
      <li><a href="#informative"><span class="secno"></span> <span class="content">Informative References</span></a>
     </ol>
    <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>This proposal allows implementations to define <em>extended floating-point types</em> in addition to the three standard floating-point types.  It defines the 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.  It specifies the rules for type conversions, arithmetic conversions, promotions, and narrowing conversions.  It specifies the necessary standard library support for the extended floating-point types.</p>
   <p>The companion paper, <a data-link-type="biblio" href="#biblio-p1468">[P1468]</a>, defines some standard names for commonly used floating-point formats.  The end goal of these two papers is to enable the use of newer floating-point types, such as IEEE 16-bit, in standard conforming code.</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="#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 the <a href="#overload">overload resolution</a> section.</p>
   <ul>
    <li data-md>
     <p>Revised floating-point <a href="#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="#implicit">implicit conversions</a>.</p>
    <li data-md>
     <p>Added the section on <a href="#overload">overload resolution</a>.</p>
    <li data-md>
     <p>Added the sections on <a href="#core-test-macro">feature test macros</a>.</p>
    <li data-md>
     <p>Added the sections about the possibility of new <a href="#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-Prague)</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="#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="#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>
   <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 and NVIDIA GPUs) 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>This paper changes the language so that implementations can support 16-bit and other non-standard floating-point types. <a data-link-type="biblio" href="#biblio-p1468">[P1468]</a> gives well-known names to 16-bit and other commonly used floating-point types.</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, 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>
   <p>The language rules in this paper and the type aliases in <a data-link-type="biblio" href="#biblio-p1468">[P1468]</a> are designed to work together to simplify the safe adoption of the new floating-point types into existing applications.  Programmers should be able to start using the 16-bit types in one part of the application without having to change other parts.  When <code class="highlight"><c- b>float</c-></code> and <code class="highlight"><c- b>double</c-></code> are IEEE-conformant types, it should be possible to mix the standard types with their fixed-layout aliases without problems.  This proposal would be a failure if code using the IEEE 64-bit type alias had to be kept mostly separate from code using <code class="highlight"><c- b>double</c-></code>.</p>
   <h2 class="heading settled" data-level="4" id="proposal"><span class="secno">4. </span><span class="content">Proposal summary</span><a class="self-link" href="#proposal"></a></h2>
   <p>In a nutshell:</p>
   <ol>
    <li data-md>
     <p>Introduce <em>extended floating-point types</em>.</p>
    <li data-md>
     <p>Define <em>floating-point conversion rank</em>, which governs how floating-point types interact with each other.</p>
    <li data-md>
     <p>Adjust the rules for promotion, standard conversions, usual arithmetic conversions, narrowing conversions, and overload resolution to make use of conversion rank.</p>
    <li data-md>
     <p>Add function overloads and template specializations for extended floating-point types to <code class="highlight"><c- o>&lt;</c-><c- n>cmath</c-><c- o>></c-></code>, <code class="highlight"><c- o>&lt;</c-><c- n>charconv</c-><c- o>></c-></code>, <code class="highlight"><c- o>&lt;</c-><c- n>format</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>
   </ol>
   <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.</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>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>
   <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 that can adapt to changing hardware without having to modify the standard.</p>
   <h4 class="heading settled" data-level="5.2.2" id="extended-wording"><span class="secno">5.2.2. </span><span class="content">Wording</span><a class="self-link" href="#extended-wording"></a></h4>
   <p>Modify 6.7.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>
   <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>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 two types have the exact same sets of values, they still have different conversion ranks; see the wording below for the exact rules.  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.  Floating-point conversion rank forms a partial order, not a total order; this is the biggest difference from integer conversion rank.</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>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 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 higher 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>
   <h4 class="heading settled" data-level="5.3.2" id="rank-wording"><span class="secno">5.3.2. </span><span class="content">Wording</span><a class="self-link" href="#rank-wording"></a></h4>
   <p>
    Change the title of section 6.7.4 [<strong>conv.rank</strong>] from "
    <del>Integer conversion rank</del>
    " to "
    <ins>Conversion ranks</ins>
    ", but leave the stable name unchanged.  Insert a new paragraph 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>The rank of any standard floating-point type is greater than the rank of any extended floating-point type with the same set of values.</p>
     <li data-md>
      <p>The rank of any extended floating-point type relative to another extended floating-point type with the same set of values is implementation-defined, but still subject to the other rules for determining the floating-point conversion rank.</p>
     <li data-md>
      <p>For all floating-point types <code class="highlight"><c- n>T1</c-></code>, <code class="highlight"><c- n>T2</c-></code>, and <code class="highlight"><c- n>T3</c-></code>, if <code class="highlight"><c- n>T1</c-></code> has greater rank than <code class="highlight"><c- n>T2</c-></code> and <code class="highlight"><c- n>T2</c-></code> has greater rank than <code class="highlight"><c- n>T3</c-></code>, then <code class="highlight"><c- n>T1</c-></code> has greater rank than <code class="highlight"><c- n>T3</c-></code>.</p>
    </ul>
    <p>[ <em>Note</em>: The conversion ranks of extended floating-point types <code class="highlight"><c- n>T1</c-></code> and <code class="highlight"><c- n>T2</c-></code> will be 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 can happen when one type has both a larger range and a lower precision than the other. -- <em>end note</em> ] [ <em>Note</em>: The floating-point conversion rank is used in the definition of the usual arithmetic conversions ([expr.arith.conv]). -- <em>end note</em> ]</p>
   </blockquote>
   <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>All floating-point types with a conversion rank that is less than the rank of <code class="highlight"><c- b>double</c-></code> promote to <code class="highlight"><c- b>double</c-></code>.  (This automatically covers arguments passed to the elipsis part of a varargs functon.)</p>
   <h4 class="heading settled" data-level="5.4.1" id="promotion-reason"><span class="secno">5.4.1. </span><span class="content">Reasoning</span><a class="self-link" href="#promotion-reason"></a></h4>
   <p>This most closely matches the integer promotion rules, though the floating-point rules are simpler due to the lack of signed/unsigned and enumeration types.</p>
   <h4 class="heading settled" data-level="5.4.2" id="promotion-wording"><span class="secno">5.4.2. </span><span class="content">Wording</span><a class="self-link" href="#promotion-wording"></a></h4>
   <p>Change section 7.3.7 "Floating-point promotion" [<strong>conv.fpprom</strong>] as follows:</p>
   <blockquote>
    <div class="numbered">
      A prvalue of
     <del>type <code class="highlight"><c- b>float</c-></code></del>
     <ins>a floating-point type whose floating-point conversion rank ([conv.rank]) is less than the rank of <code class="highlight"><c- b>double</c-></code></ins>
      can be converted to a prvalue of type <code class="highlight"><c- b>double</c-></code>. The value is unchanged.
    </div>
    <div class="numbered"> This conversion is called <em>floating-point promotion</em>. </div>
   </blockquote>
   <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>The standard currently allows implicit conversions between any arithmetic types, even if the conversion could result in a loss of information.  This can’t be changed for any existing arithmetic types, but it is possible to choose a different behavior for the new extended floating-point types.  A reasonable rule would be to allow implicit conversions between floating-point types only when converting to a type with a higher conversion rank (or when converting between two standard floating-point types, for backward compatibility).</p>
   <p>If implicit conversions are always allowed, that most closely matches existing behavior and will likely lead to fewer surprises.  If potentially lossy conversions are not implicit, that will lead to safer code.  Since explicit conversions between all floating-point types would still be allowed, potentially lossy conversions would be more verbose rather than forbidden.</p>
   <p>This issue was discussed in EWG in Belfast.  There were strong opinions on both sides of the issue.  The poll that was taken did not show consensus in either direction.  The authors of the paper are undecided on which choice is best.  So this is still an open issue.</p>
   <p>This issue is mostly independent from the rest of the paper, so it could be decided either way without invalidating the rest of the proposal.  The only area that would be affected would be overload resolution, since some standard conversions would no longer be standard conversions if implicit versions were restricted.</p>
   <p class="issue" id="issue-442ebd5c"><a class="self-link" href="#issue-442ebd5c"></a> Should implicit conversions be allowed from larger floating-point types to smaller floating-point types?</p>
   <h4 class="heading settled" data-level="5.5.1" id="implicit-example"><span class="secno">5.5.1. </span><span class="content">Example</span><a class="self-link" href="#implicit-example"></a></h4>
   <p>Assuming that extended floating-point conversions are restricted as proposed:</p>
<pre class="highlight"><code class="highlight"><c- b><c- b>double</c-></c-> <c- n><c- n>f64</c-></c-> <c- o><c- o>=</c-></c-> <c- mf><c- mf>1.0</c-></c-><c- p><c- p>;</c-></c->
<c- b><c- b>float</c-></c-> <c- n><c- n>f32</c-></c-> <c- o><c- o>=</c-></c-> <c- mf><c- mf>2.0</c-></c-><c- p><c- p>;</c-></c->
<c- n><c- n>__fp16</c-></c-> <c- n><c- n>f16</c-></c-> <c- o><c- o>=</c-></c-> <c- mf><c- mf>3.0</c-></c-><c- p><c- p>;</c-></c->
<c- n><c- n>fp64</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>fp32</c-></c-><c- p><c- p>;</c-></c-> <c- c1><c- c1>// okay</c-></c->
<c- n><c- n>fp32</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>fp64</c-></c-><c- p><c- p>;</c-></c-> <c- c1><c- c1>// okay, standard types for backward compatibility</c-></c->
<c- n><c- n>fp64</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>fp16</c-></c-><c- p><c- p>;</c-></c-> <c- c1><c- c1>// okay</c-></c->
<c- n><c- n>fp16</c-></c-> <c- o><c- o>=</c-></c-> <c- n><c- n>fp64</c-></c-><c- p><c- p>;</c-></c-> <c- c1><c- c1>// error, implicit conversion not allowed</c-></c->
<c- n><c- n>fp16</c-></c-> <c- o><c- o>=</c-></c-> <c- k><c- k>static_cast</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>__fp16</c-></c-><c- o><c- o>></c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>fp64</c-></c-><c- p><c- p>);</c-></c-> <c- c1><c- c1>// okay, explicit cast</c-></c->
</code></pre>
   <h4 class="heading settled" data-level="5.5.2" id="implicit-wording"><span class="secno">5.5.2. </span><span class="content">Wording</span><a class="self-link" href="#implicit-wording"></a></h4>
   <p>If it is decided that implicit conversions are always allowed, then no wording changes are necessary.  7.3.9 [<strong>conv.double</strong>] already does the right thing.</p>
   <p>If it is decided that implicit conversions should be restricted, then the following wording changes are necessary:</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 higher conversion rank or with the same set of values, or a prvalue of standard floating-point type can be converted to a prvalue of another standard floating-point type</ins>
     . 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 value 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 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. </div>
   </blockquote>
   <p class="note" role="note"><span>Note:</span> 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>
   <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>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.</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>In this implementation, let <code class="highlight"><c- b>float</c-></code> be IEEE <code class="highlight"><c- n>binary32</c-></code>, <code class="highlight"><c- n>__fp16</c-></code> be IEEE <code class="highlight"><c- n>binary16</c-></code>, and <code class="highlight"><c- n>__bfloat</c-></code> be 16-bit bfloat.</p>
<pre class="highlight"><code class="highlight"><c- b><c- b>float</c-></c-> <c- n><c- n>f32</c-></c-> <c- o><c- o>=</c-></c-> <c- mf><c- mf>1.0</c-></c-><c- p><c- p>;</c-></c->
<c- n><c- n>__fp16</c-></c-> <c- n><c- n>f16</c-></c-> <c- o><c- o>=</c-></c-> <c- mf><c- mf>2.0</c-></c-><c- p><c- p>;</c-></c->
<c- n><c- n>__bfloat</c-></c-> <c- n><c- n>b16</c-></c-> <c- o><c- o>=</c-></c-> <c- mf><c- mf>3.0</c-></c-><c- p><c- p>;</c-></c->
<c- n><c- n>f32</c-></c-> <c- o><c- o>+</c-></c-> <c- n><c- n>f16</c-></c-><c- p><c- p>;</c-></c-> <c- c1><c- c1>// okay, f16 converted to </c-></c-><code class="highlight"><c- c1><c- c1><c- b>float</c-></c-></c-></code><c- c1><c- c1>, result type is </c-></c-><code class="highlight"><c- c1><c- c1><c- b>float</c-></c-></c-></code>
<c- n><c- n>f32</c-></c-> <c- o><c- o>+</c-></c-> <c- n><c- n>b16</c-></c-><c- p><c- p>;</c-></c-> <c- c1><c- c1>// okay, b16 converted to </c-></c-><code class="highlight"><c- c1><c- c1><c- b>float</c-></c-></c-></code><c- c1><c- c1>, result type is </c-></c-><code class="highlight"><c- c1><c- c1><c- b>float</c-></c-></c-></code>
<c- n><c- n>f16</c-></c-> <c- o><c- o>+</c-></c-> <c- n><c- n>b16</c-></c-><c- p><c- p>;</c-></c-> <c- c1><c- c1>// error, neither type can convert to the other via arithmetic conversions</c-></c->
</code></pre>
   <h4 class="heading settled" data-level="5.6.2" id="arithmetic-wording"><span class="secno">5.6.2. </span><span class="content">Wording</span><a class="self-link" href="#arithmetic-wording"></a></h4>
   <p>Modify section 7.4 Usual arithmetic conversions [<strong>expr.arith.conv</strong>] as follows:</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 has a floating-point type, the following rules shall be 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 has a type that is not a floating-point type, that operand shall be 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, then the operand with the type of the lower floating-point conversion rank shall be 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]) shall be performed on both operands.(59) Then the following rules shall be 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 shall be 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 shall be 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 shall be converted to the type of the operand with signed integer type.</p>
        <li data-md>
         <p>Otherwise, both operands shall be 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>
   <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>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>
   <h4 class="heading settled" data-level="5.7.1" id="narrow-reason"><span class="secno">5.7.1. </span><span class="content">Same representation</span><a class="self-link" href="#narrow-reason"></a></h4>
   <p>When two different floating-point types have the same representation, one of the types has a higher conversion rank than the other.  Which means that a conversion between the two types will be a narrowing conversion in one of the directions even though the value will be preserved.  For example, on some implementations, <code class="highlight"><c- b>double</c-></code> and <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> have the same representation, but <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> always has a higher conversion rank than <code class="highlight"><c- b>double</c-></code>, so a conversion from <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> to <code class="highlight"><c- b>double</c-></code> is considered a narrowing conversion.</p>
   <p>An earlier version of this paper defined narrowing conversions in terms of sets of representable values, not in terms of conversion rank.  With that definition, conversions between types with the same representation would never be a narrowing conversion. <a href="http://wiki.edg.com/bin/view/Wg21kona2019/SG6MinutesP1468">SG6</a> in Kona preferred using conversion rank over sets of values, so the proposal was changed to the current definition.  One argument against the old definition was that it changed the behavior for standard floating-point types, as in the example of <code class="highlight"><c- b>double</c-></code> and <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> above.</p>
   <p>It would be possible to have different rules for standard floating-point types and extended floating-point types, but the authors feel it is best to maintain consistency between standard and extended types, and to not change the behavior of standard types.</p>
   <h4 class="heading settled" data-level="5.7.2" id="narrow-constant"><span class="secno">5.7.2. </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>__fp16</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 (assuming that <code class="highlight"><c- n>__fp16</c-></code> is the name of an extended floating-point type with a conversion rank lower than <code class="highlight"><c- b>double</c-></code>).</p>
   <h4 class="heading settled" data-level="5.7.3" id="narrow-wording"><span class="secno">5.7.3. </span><span class="content">Wording</span><a class="self-link" href="#narrow-wording"></a></h4>
   <p>Modify the definition of narrowing conversions in 9.3.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 not greater than 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>
   <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>When comparing standard conversion sequences that involve floating-point conversions, prefer conversions between types that have the same representation.</p>
   <h4 class="heading settled" data-level="5.8.1" id="overload-reason"><span class="secno">5.8.1. </span><span class="content">Reasoning</span><a class="self-link" href="#overload-reason"></a></h4>
   <p>The extended floating-point types should behave as much as possible as other arithmetic types, with one exception: overload resolution should prefer cases where the argument and the parameter have the same representation, even when they are different types.</p>
   <p>Overload resolution of floating-point types behaves mostly like the <code class="highlight"><c- b>int</c-></code>s, with anything smaller than <code class="highlight"><c- b>double</c-></code> promoted to <code class="highlight"><c- b>double</c-></code>.  The difference comes when choosing among standard conversions.  Unlike the <code class="highlight"><c- b>int</c-></code>s, where there is no preference among standard conversions, a conversion between two floating-point types with the same representation is preferred over a conversion between types with different representations.</p>
   <p>These rules ease the adoption of the fixed-layout type aliases defined in <a data-link-type="biblio" href="#biblio-p1468">[P1468]</a> as described at the end of the <a href="#motivation">motivation</a>.</p>
   <h4 class="heading settled" data-level="5.8.2" id="overload-example"><span class="secno">5.8.2. </span><span class="content">Examples</span><a class="self-link" href="#overload-example"></a></h4>
   <p>These examples assume that <code class="highlight"><c- b>float</c-></code> and <code class="highlight"><c- b>double</c-></code> are IEEE 32- and 64-bit types, that <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> is X87 80-bit, and that <code class="highlight"><c- n>__fp16</c-></code>, <code class="highlight"><c- n>__fp32</c-></code>, <code class="highlight"><c- n>__fp64</c-></code>, <code class="highlight"><c- n>__fp128</c-></code>, and <code class="highlight"><c- n>__bfloat</c-></code> are all extended floating-point types (distinct from <code class="highlight"><c- b>float</c-></code> and <code class="highlight"><c- b>double</c-></code>) representing IEEE 16-bit, 32-bit, 64-bit, and 128-bit types and <code class="highlight"><c- n>bfloat16</c-></code>.</p>
   <p>Given that function <code class="highlight"><c- n>f</c-></code> is overloaded on all the standard floating-point types:</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- b><c- b>float</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- b><c- b>double</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- b><c- b>long</c-></c-> <c- b><c- b>double</c-></c-><c- p><c- p>);</c-></c->
</code></pre>
   <p>Calling <code class="highlight"><c- n>f</c-></code> with an argument of type <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> will of course choose the overload with the exact match.  Calling <code class="highlight"><c- n>f</c-></code> with an argument of type <code class="highlight"><c- n>__fp16</c-></code>, <code class="highlight"><c- n>__bfloat</c-></code>, <code class="highlight"><c- n>__fp32</c-></code>, or <code class="highlight"><c- n>__fp64</c-></code> will choose <code class="highlight"><c- n>f</c-><c- p>(</c-><c- b>double</c-><c- p>)</c-></code> because all of those types promote to <code class="highlight"><c- b>double</c-></code>.  Calling <code class="highlight"><c- n>f</c-></code> with an argument of type <code class="highlight"><c- n>__f128</c-></code> will be ambiguous because there is no exact match or promotion and none of the standard conversions is preferred over the others.</p>
   <p>Given that function <code class="highlight"><c- n>g</c-></code> is overloaded on the 32-bit and 64-bit extended types:</p>
<pre class="highlight"><code class="highlight"><c- b><c- b>void</c-></c-> <c- nf><c- nf>g</c-></c-><c- p><c- p>(</c-></c-><c- n><c- n>__fp32</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- n><c- n>__fp64</c-></c-><c- p><c- p>);</c-></c->
</code></pre>
   <p>Calling <code class="highlight"><c- n>g</c-></code> with <code class="highlight"><c- n>__fp32</c-></code> or <code class="highlight"><c- n>__fp64</c-></code> will choose the overload with the exact match.  Calling <code class="highlight"><c- n>g</c-></code> with <code class="highlight"><c- b>float</c-></code> will call <code class="highlight"><c- n>g</c-><c- p>(</c-><c- n>__fp32</c-><c- p>)</c-></code> because <code class="highlight"><c- b>float</c-></code> and <code class="highlight"><c- n>__fp32</c-></code> have the same representation.  For similar reasons, calling <code class="highlight"><c- n>g</c-></code> with <code class="highlight"><c- b>double</c-></code> will call <code class="highlight"><c- n>g</c-><c- p>(</c-><c- n>__fp64</c-><c- p>)</c-></code>.  Calling <code class="highlight"><c- n>g</c-></code> with an argument of any other type will be ambiguous because the standard conversion to neither parameter is preferred over the other.</p>
   <h4 class="heading settled" data-level="5.8.3" id="overload-wording"><span class="secno">5.8.3. </span><span class="content">Wording</span><a class="self-link" href="#overload-wording"></a></h4>
   <p>In 12.3.3.2 "Ranking implicit conversion sequences" [over.ics.rank] 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) <code class="highlight"><c- n>FP1</c-></code> and <code class="highlight"><c- n>FP2</c-></code> have the same set of values, and</p>
        <li data-md>
         <p>(4.3.2) <code class="highlight"><c- n>FP1</c-></code> or <code class="highlight"><c- n>FP2</c-></code> is an extended floating-point type, and</p>
        <li data-md>
         <p>(4.3.3) <code class="highlight"><c- n>FP3</c-></code> has a different set of values from <code class="highlight"><c- n>FP1</c-></code> or the floating-point conversion rank ([conv.rank]) of <code class="highlight"><c- n>FP3</c-></code> is not less than the rank of <code class="highlight"><c- n>FP2</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>
   <p class="note" role="note"><span>Note:</span> The important parts of the proposed wording are (4.3.1) and the first half of (4.3.3).  (4.3.2) and the second half of (4.3.3) exist to give reasonable behavior when at least two of the standard floating-point types have the same representation (which is true for <code class="highlight"><c- b>double</c-></code> and <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> on many implementations).</p>
   <h4 class="heading settled" data-level="5.8.4" id="overload-alternate"><span class="secno">5.8.4. </span><span class="content">Alternate proposal</span><a class="self-link" href="#overload-alternate"></a></h4>
   <p>This paper contained a different set of rules for overload resolution in R2.  That proposal had some opposition when presented in Belfast (though no poll was taken about it), so the overload rules were revised to what is listed immediately above.  But the authors feel that the older rules have some advantages.  So the older rules are listed here in case anyone can think of a way to combine the two into a new proposal that has the advantages of both.</p>
   <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>This has the advantage that, when code overloads a function on some of the floating-point types, then calls to that function will be well-formed as long as the argument is of a floating-point type that can be safely converted to at least one of the possible parameter types.</p>
   <p>For example, let <code class="highlight"><c- b>float</c-></code> be IEEE 32-bit, <code class="highlight"><c- b>double</c-></code> be IEEE 64-bit, and <code class="highlight"><c- b>long</c-> <c- b>double</c-></code> be X87 80-bit.  And let <code class="highlight"><c- n>__fp16</c-></code>, <code class="highlight"><c- n>__fp32</c-></code>, and <code class="highlight"><c- n>__fp64</c-></code> be extended floating-point types that represent IEEE 16-bit, 32-bit, and 64-bit respectively.  Then given a function overloaded on the 32-bit and 64-bit extended floating-point types:</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>__fp32</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>__fp64</c-></c-><c- p><c- p>);</c-></c-></code></pre>
   <p>The following functions calls should be well-formed:</p>
<pre class="highlight"><code class="highlight"><c- n><c- n>f</c-></c-><c- p><c- p>((</c-></c-><c- n><c- n>__fp16</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 f(__fp32)</c-></c->
<c- n><c- n>f</c-></c-><c- p><c- p>((</c-></c-><c- n><c- n>__fp32</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 f(__fp32)</c-></c->
<c- n><c- n>f</c-></c-><c- p><c- p>((</c-></c-><c- n><c- n>__fp64</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 f(__fp64)</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>4.0</c-></c-><c- p><c- p>);</c-></c->  <c- c1><c- c1>// calls f(__fp32)</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>5.0</c-></c-><c- p><c- p>);</c-></c-> <c- c1><c- c1>// calls f(__fp64)</c-></c-></code></pre>
   <p>But the function call <code class="highlight"><c- n>f</c-><c- p>((</c-><c- b>long</c-> <c- b>double</c-><c- p>)</c-><c- mf>6.0</c-><c- p>);</c-></code> would be an ambiguous function call.</p>
   <p>The disadvantage of this proposal (and the reason for the opposition to it in Belfast) is that adding a new overload of an existing function can change the function that is called without the new overload being an exact match for the argument type.</p>
   <p>In 12.3.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>F1</c-></code> to floating-point type <code class="highlight"><c- n>F2</c-></code> is better than a conversion from <code class="highlight"><c- n>F1</c-></code> to floating-point type <code class="highlight"><c- n>F3</c-></code> if the set of values of <code class="highlight"><c- n>F1</c-></code> is a subset of the set of values of <code class="highlight"><c- n>F2</c-></code> and <code class="highlight"><c- n>F3</c-></code> has greater floating-point conversion rank ([conv.rank]) than <code class="highlight"><c- n>F2</c-></code>.</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="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>Pointers to two different floating-point types can be freely and implicitly converted between each other as long as the two floating-point types have the same representation.</p>
   <h4 class="heading settled" data-level="5.9.1" id="pointer-reason"><span class="secno">5.9.1. </span><span class="content">Reasoning</span><a class="self-link" href="#pointer-reason"></a></h4>
   <p>These pointer conversions will ease the transition to the fixed-layout aliases.  There is lots of existing floating-point code that uses pointer-to-<code class="highlight"><c- b>float</c-></code> or pointer-to-<code class="highlight"><c- b>double</c-></code> as function parameters.  When compilers implement <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code> (or whatever name is chosen as the name for the IEEE 64-bit type in <a data-link-type="biblio" href="#biblio-p1468">[P1468]</a>), users on systems where <code class="highlight"><c- b>double</c-></code> is IEEE 64-bit can change their parameters and variables from <code class="highlight"><c- b>double</c-></code> to <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code> incrementally.  With the pointer conversions and <a href="#overload">overload resolution</a> rules above, <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> will essentially behave as if they were the same type even though they are different types.  Users do not have to change their code from <code class="highlight"><c- b>double</c-></code> to <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code> all at once and don’t have to coordinate the change with third-party library vendors.  (Changing code to use <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code> instead of <code class="highlight"><c- b>double</c-></code> is a good thing for many users because it more clearly communicates the author’s intent.)</p>
   <p>If the user is on a system where <code class="highlight"><c- b>double</c-></code> is not IEEE 64-bit (or later ports to such a system), then <code class="highlight"><c- p>(</c-><c- b>double</c-> <c- o>*</c-><c- p>)</c-></code> will not implicitly convert to <code class="highlight"><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-> <c- o>*</c-><c- p>)</c-></code>.  In that environment the switch from <code class="highlight"><c- b>double</c-></code> to <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code> has to be well-coordinated and can’t be done piecemeal.  The compiler will help with that by reporting a compilation error when such implicit pointer conversions are attempted.</p>
   <p>If these pointer conversions are not implicit, then a user switching code from <code class="highlight"><c- b>double</c-></code> to <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>float64_t</c-></code> would likely have to add <code class="highlight"><c- k>static_cast</c-></code>s to the code in some places.  In addition to being more work, this leaves the code more fragile and error prone, because there will be runtime failures rather than compilation errors if the code is later ported to a system where <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> do not have the same representation.</p>
   <h4 class="heading settled" data-level="5.9.2" id="pointer-wording"><span class="secno">5.9.2. </span><span class="content">Wording</span><a class="self-link" href="#pointer-wording"></a></h4>
   <p>Add a new paragraph to the end of section 7.3.11 "Pointer conversions" [<strong>conv.ptr</strong>]:</p>
   <blockquote class="ins">
    <p>A prvalue of type "pointer to <em>cv</em> <code class="highlight"><c- n>F1</c-></code>", where <code class="highlight"><c- n>F1</c-></code> is a floating-point type, can be converted to a prvalue of type "pointer to <em>cv</em> <code class="highlight"><c- n>F2</c-></code>", where <code class="highlight"><c- n>F2</c-></code> is a different floating-point type with the same set of values as <code class="highlight"><c- n>F1</c-></code>.  The pointer value is unchanged by this conversion.</p>
   </blockquote>
   <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 defined in <a data-link-type="biblio" href="#biblio-p1468">[P1468]</a>.  So it might be useful to have a feature test macro that indicates support for extended floating-point types listed in 15.10 [<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.</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.  (The companion paper, <a data-link-type="biblio" href="#biblio-p1468">[P1468]</a>, does add new names related to floating-point types to the standard library.  But those names are not necessary to make extended floating-point types useful.)</p>
   <p>To handle I/O of extended floating-point types, changes are proposed to <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>format</c-><c- o>></c-></code>, but not to <code class="highlight"><c- o>&lt;</c-><c- n>iostream</c-><c- o>></c-></code> or <code class="highlight"><c- o>&lt;</c-><c- n>cstdio</c-><c- o>></c-></code>.</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.  No changes are proposed to <code class="highlight"><c- o>&lt;</c-><c- n>cfloat</c-><c- o>></c-></code>; users should use <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>numeric_limits</c-></code> instead 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 format specifiers for implementation-specific types with implementation-specific names.</p>
    <li data-md>
     <p>I/O streams:  To support extended floating-point types, new virtual functions would need to be added to <code class="highlight"><c- n>num_get</c-></code> and <code class="highlight"><c- n>num_put</c-></code>, which would be an ABI break.</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 support extended floating-point types either.</p>
   </ul>
   <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, there are some new things that could be useful.  The authors are undecided if these are useful enough to be worth adding, and would appreciate LEWG feedback on the matter.</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.  Should the standard also provide <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>?  Will users need to distinguish between standard and extended types often enough that <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> becomes too unwieldy?</p>
   <p class="issue" id="issue-5b95c8c1"><a class="self-link" href="#issue-5b95c8c1"></a> Should the new type traits <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> be introduced?</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>Should there be a type trait that reports whether or not one floating-point type has a higher conversion rank than another?  This could be useful when writing function templates to figure out which conversions between different floating-point 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 where this trait would be useful.</p>
   <p class="issue" id="issue-4dff46e4"><a class="self-link" href="#issue-4dff46e4"></a> Should a new type trait be introduced that can be used to query the floating-point conversion rank relationship?</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>
   <h4 class="heading settled" data-level="6.2.1" id="charconv-wording"><span class="secno">6.2.1. </span><span class="content">Wording</span><a class="self-link" href="#charconv-wording"></a></h4>
   <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>
    <del><em>Requires</em></del>
    <ins><em>Expects</em></ins>
    : <code class="highlight"><c- n>base</c-></code> has a value between 2 and 36 (inclusive).
    <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>
    <del><em>Requires</em></del>
    <ins><em>Expects</em></ins>
    : <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><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>
    <del><em>Requires</em></del>
    <ins><em>Expects</em></ins>
    : <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><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">
     <del><em>Requires</em></del>
     <ins><em>Expects</em></ins>
     : <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">
     <del><em>Requires</em></del>
     <ins><em>Expects</em></ins>
     : <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>
   <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>Change <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>format</c-></code> to support extended floating-point types.</p>
   <h4 class="heading settled" data-level="6.3.1" id="format-wording"><span class="secno">6.3.1. </span><span class="content">Wording</span><a class="self-link" href="#format-wording"></a></h4>
   <p>... to be determined ...</p>
   <h3 class="heading settled" data-level="6.4" id="cmath"><span class="secno">6.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"></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>
   <h4 class="heading settled" data-level="6.4.1" id="cmath-wording"><span class="secno">6.4.1. </span><span class="content">Wording</span><a class="self-link" href="#cmath-wording"></a></h4>
   <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 highest floating-point conversion rank ([conv.rank]) 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- nf><c- nf>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- nf><c- nf>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- nf><c- nf>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>
   <h3 class="heading settled" data-level="6.5" id="complex"><span class="secno">6.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"></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 template through <code class="highlight"><c- k>explicit</c-><c- p>(</c-><c- b>bool</c-><c- p>)</c-></code>.</p>
   <h4 class="heading settled" data-level="6.5.1" id="complex-wording"><span class="secno">6.5.1. </span><span class="content">Wording</span><a class="self-link" href="#complex-wording"></a></h4>
   <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 2:</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>Ensures</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-> <c- o>&amp;&amp;</c-> <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 false if and only if the floating-point conversion rank of <code class="highlight"><c- n>T</c-></code> is greater than the floating-point conversion rank of <code class="highlight"><c- n>X</c-></code>.</p>
   </blockquote>
   <p>In 26.4.6 "Non-member operations" [<strong>complex.ops</strong>], change the streaming operators as follows:</p>
   <blockquote>
<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>T</c-></c-><c- p><c- p>,</c-></c-> <c- k><c- k>class</c-></c-> <c- nc><c- nc>CharT</c-></c-><c- p><c- p>,</c-></c-> <c- k><c- k>class</c-></c-> <c- nc><c- nc>traits</c-></c-><c- o><c- o>></c-></c->
  <c- n><c- n>basic_istream</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- 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>&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- n><c- n>is</c-></c-><c- p><c- p>,</c-></c-> <c- n><c- n>complex</c-></c-><c- o><c- o>&lt;</c-></c-><c- n><c- n>T</c-></c-><c- o><c- o>>&amp;</c-></c-> <c- n><c- n>x</c-></c-><c- p><c- p>);</c-></c->
</code></pre>
    <ins><em>Constraints</em>: <code class="highlight"><c- n>T</c-></code> is a standard floating-point type.</ins>
    <p>
     <del><em>Requires</em></del>
     <ins><em>Expects</em></ins>
     : The input values
     <del>shall be</del>
     <ins>are</ins>
      convertible to <code class="highlight"><c- n>T</c-></code>.
    </p>
    <p><em>Effects</em>: Extracts a complex number <code class="highlight"><c- n>x</c-></code> of the form: <code class="highlight"><c- n>u</c-></code>, <code class="highlight"><c- p>(</c-><c- n>u</c-><c- p>)</c-></code>, or <code class="highlight"><c- p>(</c-><c- n>u</c-><c- p>,</c-><c- n>v</c-><c- p>)</c-></code>, where <code class="highlight"><c- n>u</c-></code> is the real part and <code class="highlight"><c- n>v</c-></code> is the imaginary part (29.7.4.2).</p>
    <p>If bad input is encountered, calls <code class="highlight"><c- n>is</c-><c- p>.</c-><c- n>setstate</c-><c- p>(</c-><c- n>ios_base</c-><c- o>::</c-><c- n>failbit</c-><c- p>)</c-></code> (which may throw <code class="highlight"><c- n>ios</c-><c- o>::</c-><c- n>failure</c-></code> (29.5.5.4)).</p>
    <p><em>Returns</em>: <code class="highlight"><c- n>is</c-></code>.</p>
    <p><em>Remarks</em>: This extraction is performed as a series of simpler extractions. Therefore, the skipping of whitespace is specified to be the same for each of the simpler extractions.</p>
<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>T</c-></c-><c- p><c- p>,</c-></c-> <c- k><c- k>class</c-></c-> <c- nc><c- nc>charT</c-></c-><c- p><c- p>,</c-></c-> <c- k><c- k>class</c-></c-> <c- nc><c- nc>traits</c-></c-><c- o><c- o>></c-></c->
  <c- n><c- n>basic_ostream</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- 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>&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- n><c- n>o</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>T</c-></c-><c- o><c- o>>&amp;</c-></c-> <c- n><c- n>x</c-></c-><c- p><c- p>);</c-></c->
</code></pre>
    <ins><em>Constraints</em>: <code class="highlight"><c- n>T</c-></code> is a standard floating-point type.</ins>
    <p><em>Effects</em>: Inserts the complex number <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 different and 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>, 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>
   <p class="note" role="note"><span>Note:</span> No literal suffixes are defined for complex numbers of extended floating-point types.  Subclause [complex.literals] is unchanged.</p>
   <h3 class="heading settled" data-level="6.6" id="atomic"><span class="secno">6.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"></a></h3>
   <p>Change the wording so that the specializations of <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>atomic</c-></code> for floating-point types apply to all floating-point types, not just the standard floating-point types listed.</p>
   <p>The specializations of <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>atomic</c-></code> for integral types are not required to include specializations for all extended integral types, only for the extended types that are used in <code class="highlight"><c- o>&lt;</c-><c- n>cstdint</c-><c- o>></c-></code>.  It would be reasonable for this proposal to adopt a similar approach.  If we take that approach, there are no wording changes to <code class="highlight"><c- o>&lt;</c-><c- n>atomic</c-><c- o>></c-></code> in this paper.  Instead, there would be some changes to <code class="highlight"><c- o>&lt;</c-><c- n>atomic</c-><c- o>></c-></code> as part of <a data-link-type="biblio" href="#biblio-p1468">[P1468]</a>, requiring specializations only for the floating-point aliases that name extended floating-point types.</p>
   <p class="issue" id="issue-212f8c60"><a class="self-link" href="#issue-212f8c60"></a> Should <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>atomic</c-></code> have specializations for all floating-point types, or only for extended floating-point types with well-known aliases (see <a data-link-type="biblio" href="#biblio-p1468">[P1468]</a>)?</p>
   <h4 class="heading settled" data-level="6.6.1" id="atomic-wording"><span class="secno">6.6.1. </span><span class="content">Wording</span><a class="self-link" href="#atomic-wording"></a></h4>
   <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
    <del>the</del>
    <ins>all</ins>
     floating-point types
    <del><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></del>
    . 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>
   <h3 class="heading settled" data-level="6.7" id="lib-test-macro"><span class="secno">6.7. </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 paper.  The library changes would be covered by the core language <a href="#core-test-macro">feature test macro</a>, if there is one.</p>
  </main>
<script>
(function() {
  "use strict";
  var collapseSidebarText = '<span aria-hidden="true">←</span> '
                          + '<span>Collapse Sidebar</span>';
  var expandSidebarText   = '<span aria-hidden="true">→</span> '
                          + '<span>Pop Out Sidebar</span>';
  var tocJumpText         = '<span aria-hidden="true">↑</span> '
                          + '<span>Jump to Table of Contents</span>';

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

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

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

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

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

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


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

    tocNav.appendChild(toggle);
  }

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

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

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

})();
</script>
  <h2 class="no-num no-ref heading settled" id="references"><span class="content">References</span><a class="self-link" href="#references"></a></h2>
  <h3 class="no-num no-ref heading settled" id="informative"><span class="content">Informative References</span><a class="self-link" href="#informative"></a></h3>
  <dl>
   <dt id="biblio-p0192">[P0192]
   <dd>Michał Dominiak; et al. <a href="https://wg21.link/P0192">`short float` and fixed-size floating point types</a>. URL: <a href="https://wg21.link/P0192">https://wg21.link/P0192</a>
   <dt id="biblio-p1468">[P1468]
   <dd>Michał Dominiak; Boris Fomitchev; Sergei Nikolaev. <a href="https://wg21.link/P1468">Fixed-layout floating-point type aliasess</a>. URL: <a href="https://wg21.link/P1468">https://wg21.link/P1468</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 implicit conversions be allowed from larger floating-point types to smaller floating-point types?<a href="#issue-442ebd5c"> ↵ </a></div>
   <div class="issue"> Should there be a feature test macro to indicate that the implementation supports at least one extended floating-point type?<a href="#issue-6daed810"> ↵ </a></div>
   <div class="issue"> Should the new type traits <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> be introduced?<a href="#issue-5b95c8c1"> ↵ </a></div>
   <div class="issue"> Should a new type trait be introduced that can be used to query the floating-point conversion rank relationship?<a href="#issue-4dff46e4"> ↵ </a></div>
   <div class="issue"> Should <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>atomic</c-></code> have specializations for all floating-point types, or only for extended floating-point types with well-known aliases (see <a data-link-type="biblio" href="#biblio-p1468">[P1468]</a>)?<a href="#issue-212f8c60"> ↵ </a></div>
  </div>
