<div dir="ltr"><h1 class="gmail-title" style="line-height:1;text-align:center">Standard terminology character sets and encodings</h1><table style="border:none;border-collapse:collapse;margin-left:auto;margin-right:auto;margin-top:0.8em;float:right"><tbody><tr><td style="padding-left:1em;padding-right:1em;vertical-align:top">Document #:</td><td style="padding-left:1em;padding-right:1em;vertical-align:top">P1859R0</td></tr><tr><td style="padding-left:1em;padding-right:1em;vertical-align:top">Date:</td><td style="padding-left:1em;padding-right:1em;vertical-align:top">2019-10-06</td></tr><tr><td style="padding-left:1em;padding-right:1em;vertical-align:top">Project:</td><td style="padding-left:1em;padding-right:1em;vertical-align:top">Programming Language C++<br>SG16<br>EWG<br>CWG<br></td></tr><tr><td style="padding-left:1em;padding-right:1em;vertical-align:top">Reply-to:</td><td style="padding-left:1em;padding-right:1em;vertical-align:top">Steve Downey<br>&lt;<a href="mailto:sdowney@gmail.com" class="email" style="text-decoration-line:none;color:rgb(65,131,196)">sdowney@gmail.com</a>, <a href="mailto:sdowney2@bloomberg.net" class="email" style="text-decoration-line:none;color:rgb(65,131,196)">sdowney2@bloomberg.net</a>&gt;<br></td></tr></tbody></table><div style="color:rgb(0,0,0);font-family:serif;font-size:medium;clear:both"><p>Abstract: This document proposes new standard terms for the various encodings for character and string literals, and the encodings associated with some character types. It also proposes that the wording used for [lex.charset], [lex.ccon], [lex.string], and [basic.fundamental] 8 be modified to reflect the new terminology. This paper does not intend to propose any changes that would require changes in any currently conforming implementation.</p><h1 id="gmail-introduction" style="line-height:1"><span class="gmail-header-section-number" style="display:inline-block;min-width:35pt">1</span> Introduction<a href="#introduction" class="gmail-self-link" style="text-decoration-line:none;color:rgb(65,131,196);height:2em;text-align:center;border:none;opacity:0.5;font-family:sans-serif;font-weight:normal;font-size:26.56px"></a></h1><p>In discussions around understanding the current capabilities of C++ and proposing new capabilities and facilities, SG16 has found that the current standard wording is often unclear, and does not match well the language currently used in 10646 and the Unicode Standard. This makes having technical discussions difficult. For example, the phrase “execution encoding” often comes up, or “presumed execution encoding”, trying to describe the encodings of <code style="white-space:pre-wrap">char</code> literals and strings as interpreted by the character classification functions. This conflates several concepts, and is not actually standard terminology. It would be useful to have standard terminology that did cover these concepts.</p><p>Execution character set is a standard term, however it defines what <em>abstract characters</em> must be included in the <em>character repertoire</em> of the character set used to encode C++, specifically the various kinds of character literals. That character set is a strict superset of the source character set, which defines the <em>abstract characters</em> must be in the <em>character repertoire</em> of the character set used to write C++ source code. The encodings of those character sets are not specified, and in fact there may be several encodings used depending on the context or kind of literal.</p><p>There are five encodings that are associated with the five kinds of character literals, corresponding to <code style="white-space:pre-wrap">char</code>, <code style="white-space:pre-wrap">wchar_t</code>, <code style="white-space:pre-wrap">char8_t</code>, <code style="white-space:pre-wrap">char16_t</code>, and <code style="white-space:pre-wrap">char32_t</code>. For 8, 16, and 32, the encodings must be UTF-8, UTF-16, and UTF-32. There are no associated encodings for <code style="white-space:pre-wrap">unsigned char</code> or <code style="white-space:pre-wrap">signed char</code>.</p><p>The encoding used for narrow and wide character and string literals is implementation defined, and is, of course, fixed at translation time.</p><p>At runtime, however, interpretation of character data is usually controlled by <code style="white-space:pre-wrap">locale</code>, either explicitly, or via the <code style="white-space:pre-wrap">locale</code> specified by <code style="white-space:pre-wrap">setlocale()</code>. The dynamic locale may not be the same as the literal encoding used at translation time. This is a source of errors in text processing.</p><p>Another source of problems is the baked in assumption that a single <code style="white-space:pre-wrap">wchar_t</code> can encode any representation character. For ABIs where <code style="white-space:pre-wrap">wchar_t</code> is 16 bits, this is not true, and many of the NTMBS functions are incomplete, as they do not allow for stateful wide character encodings.</p><h1 id="gmail-terms" style="line-height:1"><span class="gmail-header-section-number" style="display:inline-block;min-width:35pt">2</span> Terms<a href="#terms" class="gmail-self-link" style="text-decoration-line:none;color:rgb(65,131,196);height:2em;text-align:center;border:none;opacity:0.5;font-family:sans-serif;font-weight:normal;font-size:26.56px"></a></h1><dl><dt>Literal Encoding</dt><dd>The encoding used for character and wide character and string literals in a translation unit.</dd><dt>Dynamic Encoding</dt><dd>The encoding implied by the LC_CTYPE category of locale.</dd><dt>Character Set [<a href="https://unicode.org/glossary/#character_set">https://unicode.org/glossary/#character_set</a>]</dt><dd>A collection of elements used to represent textual information.</dd><dt>Abstract Character [<a href="https://unicode.org/glossary/#abstract_character">https://unicode.org/glossary/#abstract_character</a>]</dt><dd>A unit of information used for the organization, control, or representation of textual data.</dd><dt>Character Repertoire [<a href="https://unicode.org/glossary/#character_repertoire">https://unicode.org/glossary/#character_repertoire</a>]</dt><dd>The collection of characters included in a character set.</dd><dt>Basic source character set</dt><dd>The abstract characters that must be representable in the character set used for source code</dd><dt>Basic execution character set</dt><dd>The abstract characters the character repertoire of the character set used for literals must include. A superset of the abstract characters in the basic source character set.</dd><dt>Execution character set</dt><dd>The set of abstract characters representable by a <code style="white-space:pre-wrap">char</code> or <code style="white-space:pre-wrap">char</code> string literal</dd><dt>Execution wide-character set</dt><dd>The set of abstract characters representable by a <code style="white-space:pre-wrap">wchar_t</code> or <code style="white-space:pre-wrap">wchar_t</code> string literal</dd></dl><h1 id="example-of-use-not-an-actual-proposal-yet" style="line-height:1"><span class="gmail-header-section-number" style="display:inline-block;min-width:35pt">3</span> Example of use (not an actual proposal, yet)<a href="#example-of-use-not-an-actual-proposal-yet" class="gmail-self-link" style="text-decoration-line:none;color:rgb(65,131,196);height:2em;text-align:center;border:none;opacity:0.5;font-family:sans-serif;font-weight:normal;font-size:26.56px"></a></h1><h2 id="gmail-proposal-dnnnn" style="line-height:1"><span class="gmail-header-section-number" style="display:inline-block;min-width:35pt">3.1</span> Proposal Dnnnn<a href="#proposal-dnnnn" class="gmail-self-link" style="text-decoration-line:none;color:rgb(65,131,196);height:2em;text-align:center;border:none;opacity:0.5;font-family:sans-serif;font-weight:normal;font-size:19.92px"></a></h2><h3 id="gmail-literal_encoding" style="line-height:1"><span class="gmail-header-section-number" style="display:inline-block;min-width:35pt">3.1.1</span> <code style="white-space:pre-wrap">literal_encoding</code><a href="#literal_encoding" class="gmail-self-link" style="text-decoration-line:none;color:rgb(65,131,196);height:2em;text-align:center;border:none;opacity:0.5;font-family:sans-serif;font-weight:normal;font-size:15.5376px"></a></h3><p>Returns an <em>unspecified</em> callable taking a <code style="white-space:pre-wrap">range</code> of elements of type <code style="white-space:pre-wrap">char</code> and returning a <code style="white-space:pre-wrap">view</code> of of code points decoded from the input range treating them as being in the <em>literal encoding</em> used for the current translation unit.</p><h3 id="gmail-wide_literal_encoding" style="line-height:1"><span class="gmail-header-section-number" style="display:inline-block;min-width:35pt">3.1.2</span> <code style="white-space:pre-wrap">wide_literal_encoding</code><a href="#wide_literal_encoding" class="gmail-self-link" style="text-decoration-line:none;color:rgb(65,131,196);height:2em;text-align:center;border:none;opacity:0.5;font-family:sans-serif;font-weight:normal;font-size:15.5376px"></a></h3><p>Returns an <em>unspecified</em> callable taking a <code style="white-space:pre-wrap">range</code> of elements of type <code style="white-space:pre-wrap">char</code> and returning a <code style="white-space:pre-wrap">view</code> of of code points decoded from the input range treating them as being in the <em>wide literal encoding</em> used for the current translation unit.</p><h2 id="gmail-discussion-of-proposal-dnnnn" style="line-height:1"><span class="gmail-header-section-number" style="display:inline-block;min-width:35pt">3.2</span> Discussion of proposal Dnnnn<a href="#discussion-of-proposal-dnnnn" class="gmail-self-link" style="text-decoration-line:none;color:rgb(65,131,196);height:2em;text-align:center;border:none;opacity:0.5;font-family:sans-serif;font-weight:normal;font-size:19.92px"></a></h2><p>Still woefully underspecified, it is at least clear what is being discussed, and how it might be something a compiler could implement. Without the terms <em>literal encoding</em> and <em>wide literal encoding</em> discussion gets bogged down quickly around the difference between what the compiler does and what locale and the <em>dynamic encoding</em> imply for character conversions.</p><h1 id="gmail-wording" style="line-height:1"><span class="gmail-header-section-number" style="display:inline-block;min-width:35pt">4</span> Wording<a href="#wording" class="gmail-self-link" style="text-decoration-line:none;color:rgb(65,131,196);height:2em;text-align:center;border:none;opacity:0.5;font-family:sans-serif;font-weight:normal;font-size:26.56px"></a></h1><p><span class="gmail-marginalizedparent" style="left: -5em;"><a class="gmail-marginalized" style="color:rgb(65,131,196);font-size:12px;text-align:right;width:5em">(lex.charset.1)</a></span>The basic source character set consists of 96 <span class="gmail-add" style="color:rgb(0,110,40)"><ins>abstract</ins></span> characters: the space character, the control characters representing horizontal tab, vertical tab, form feed, and new-line, plus the following 91 graphical characters:</p><div class="gmail-sourceCode" id="gmail-cb1" style="margin:1em 0px;overflow:auto;background-color:rgb(246,248,250)"><pre class="gmail-sourceCode gmail-default" style="margin-top:0px;margin-bottom:0px"><code class="gmail-sourceCode gmail-default" style=""><span id="gmail-cb1-1" style="color:inherit;text-decoration:inherit;display:inline-block;line-height:1.25"><a href="#cb1-1" style="text-decoration-line:none;color:rgb(65,131,196)"></a>a b c d e f g h i j k l m n o p q r s t u v w x y z</span>
<span id="gmail-cb1-2" style="color:inherit;text-decoration:inherit;display:inline-block;line-height:1.25"><a href="#cb1-2" style="text-decoration-line:none;color:rgb(65,131,196)"></a>A B C D E F G H I J K L M N O P Q R S T U V W X Y Z</span>
<span id="gmail-cb1-3" style="color:inherit;text-decoration:inherit;display:inline-block;line-height:1.25"><a href="#cb1-3" style="text-decoration-line:none;color:rgb(65,131,196)"></a>0 1 2 3 4 5 6 7 8 9</span>
<span id="gmail-cb1-4" style="color:inherit;text-decoration:inherit;display:inline-block;line-height:1.25"><a href="#cb1-4" style="text-decoration-line:none;color:rgb(65,131,196)"></a>_ { } \[ \] # ( ) &lt; &gt; % : ; . ? * + - / ^ &amp; | ~ ! = , \ &quot; &#39;</span></code></pre></div><p>[Editorial Note: Should really be a list of unicode names or universal names, aka code points e.g. LATIN CAPITAL LETTER A LATIN CAPITAL LETTER B]</p><p><span class="gmail-marginalizedparent" style="left: -5em;"><a class="gmail-marginalized" style="color:rgb(65,131,196);font-size:12px;text-align:right;width:5em">(lex.charset.3)</a></span>The basic execution character set and the basic execution wide-character set shall each contain all the <span class="gmail-rm" style="color:rgb(191,3,3)"><del>members</del></span> <span class="gmail-add" style="color:rgb(0,110,40)"><ins>abstract characters</ins></span> of the basic source character set, plus control characters representing alert, backspace, and carriage return, plus a null character (respectively, null wide character), whose value is 0. For each <span class="gmail-add" style="color:rgb(0,110,40)"><ins>element in the</ins></span> basic execution character set, the <span class="gmail-add" style="color:rgb(0,110,40)"><ins>encoded</ins></span> values of the members shall be non-negative and distinct from one another. In both the source and execution basic character sets, the value of each character after 0 in the above list of decimal digits shall be one greater than the value of the previous. The execution character set and the execution wide-character set are implementation-defined supersets of the basic execution character set and the basic execution wide-character set, respectively. The <span class="gmail-add" style="color:rgb(0,110,40)"><ins>encoded</ins></span> values of the members of the execution character sets <span class="gmail-rm" style="color:rgb(191,3,3)"><del>and the sets of additional members</del></span> are <span class="gmail-add" style="color:rgb(0,110,40)"><ins>implementation defined</ins></span><span class="gmail-rm" style="color:rgb(191,3,3)"><del>locale-specific</del></span>.</p><p>[lex.conn.2] A character literal that does not begin with u8, u, U, or L is an ordinary character literal. An ordinary character literal that contains a single c-char representable in the execution character set has type char, with value equal to the numerical value of <span class="gmail-rm" style="color:rgb(191,3,3)"><del>the encoding of</del></span> the c-char in the <span class="gmail-add" style="color:rgb(0,110,40)"><ins>literal encoding</ins></span>. An ordinary character literal that contains more than one c-char is a multicharacter literal. A multicharacter literal, or an ordinary character literal containing a single c-char not representable in the execution character set, is conditionally-supported, has type int, and has an implementation-defined value.</p><p>[lex.conn.6] A character literal that begins with the letter L, such as L’z’, is a wide-character literal. A wide-character literal has type <code style="white-space:pre-wrap">wchar_t</code>. The value of a wide-character literal containing a single c-char has value equal to the numerical value of the encoding of the c-char in the <span class="gmail-rm" style="color:rgb(191,3,3)"><del>execution wide-character set</del></span><span class="gmail-add" style="color:rgb(0,110,40)"><ins>wide literal encoding</ins></span>, unless the c-char has no representation in the execution wide-character set, in which case the value is implementation-defined. <span class="gmail-rm" style="color:rgb(191,3,3)"><del>[ Note: The type wchar_t is able to represent all members of the execution wide-character set (see [basic.fundamental]). — end note ]</del></span> The value of a wide-character literal containing multiple c-chars is implementation-defined.</p></div></div>