<div dir="ltr">Character repertoire sounds good, and I will eventually learn to spell it. Character set is definitely terminology from the pre-unicode times, and unfortunately tends to merge the repertoire and encoding, <a href="https://www.iana.org/assignments/character-sets/character-sets.xhtml">https://www.iana.org/assignments/character-sets/character-sets.xhtml</a><br><br>Basic source character set is defined in [lex.charset] <a href="http://eel.is/c++draft/lex.charset#def:character_set,basic_source">http://eel.is/c++draft/lex.charset#def:character_set,basic_source</a><br><br>I&#39;d like to get away from &quot;execution encoding&quot; because it conflates the presumed encoding and the one selected by the current locale. Now, admittedly, everyone conflates these and it&#39;s a source of error and mojibake, but perhaps with better words it would be easier to teach. <br><br>As to UB. I&#39;d like, if possible, to avoid creating new UB classes. Some things should probably be ill-formed, like unencodable characters. Others fall into existing UB, like specifying an inline string literal with two different encodings. Reading a string with the wrong encoding, I think, should be at worst unspecified, unless for some reason your decoder has UB, in which case it&#39;s the decoders problem, not the incorrect or mixed encoding isssue. That said, I&#39;d defer to Core on this. <br><br>Internal encoding is required to preserve distinct universal character names and treat all representations of the same universal character the same. So, the standard effectively requires unicode, but in terms of observables. <br><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 8, 2019 at 5:39 AM Corentin Jabot &lt;<a href="mailto:corentinjabot@gmail.com">corentinjabot@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 8 Sep 2019 at 05:46, Tom Honermann &lt;<a href="mailto:tom@honermann.net" target="_blank">tom@honermann.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <div class="gmail-m_1528546080172065353gmail-m_7194630821368723447moz-cite-prefix">On 9/5/19 9:41 PM, Steve Downey wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Because I needed to circulate what I&#39;m doing for
        Belfast, I&#39;ve thrown together an abstract for the paper we&#39;ve
        peripherally discussed about modernizing and tightening the
        specification around encodings of characters generally, and the
        source and execution character sets. <br>
        <br>
        &quot;<br>
        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.<br>
        &quot;<br>
        <br>
        I&#39;m hoping to have some preliminary work by the next telecon.
        The direction I&#39;m thinking is that both Source and Execution
        Character Set are descriptions of the abstract characters,
        selected from 10646, that must be present to support C++.
        Encodings, both source and execution, are implementation
        defined. I would like to introduce terminology to describe the
        encoding used when translating narrow and wide character and
        string literals. I&#39;d also like to make it explicit somewhere up
        front that there are associated encodings for some, but not all,
        character types. This is mentioned now in filesystem, but should
        be moved to a section with wider scope. The encoding for `char`
        and `wchar_t` is controlled by `locale`. The encoding for the
        unicode character types is fixed. The encoding used for literals
        was chosen at compile time, and is implementation defined. If
        locale and that endcoding conflict, behavior is unspecified.
        Combining TU with different encodings is in general unspecified,
        unless it results in an ODR violation. <br>
      </div>
    </blockquote>
    This all sounds great.  My only question is behavior being
    unspecified vs undefined.  It seems challenging to get away with
    making it only unspecified.<br></div></blockquote><div><br></div><div>Specifically, I&#39;d like something along the line of:</div><div>If a character literal contains a c-char that do not have the same representation in the character literal encoding (aka *presumed&quot; execution encoding) and the execution encoding, the behavior is undefined.</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    <blockquote type="cite">
      <div dir="ltr"><br>
        Some possible terms:<br>
        {&quot;&quot;,Narrow,Wide} Literal Encoding - encoding on char and string
        literals<br>
        Dynamic Encoding - encoding implied by locale<br>
        *Character Set - A set of abstract characters ( Latin Capital
        letter A, Digit Zero, Left Parenthesis ...)<br>
      </div>
    </blockquote>
    Unicode uses &quot;character repertoire&quot; for abstract sets of
    characters.  I favor following suit there.<br></div></blockquote><div><br></div><div>+1 to sticking to Unicode terms </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    <blockquote type="cite">
      <div dir="ltr">*Basic Character Set - minimum required to be
        encoded<br>
        *Extended Character Set - what can be encoded<br>
        *Source Character Set - must be encodable in C++ source<br>
      </div>
    </blockquote>
    I don&#39;t think &quot;source character set&quot; is defined today.  The closest
    we get is &quot;Physical source file characters&quot; in <a href="http://eel.is/c++draft/lex.phases#1.1" target="_blank">[lex.phases]p1</a>.<br>
    <blockquote type="cite">
      <div dir="ltr">*Execution Character Set - Source + control
        characters<br></div></blockquote></div></blockquote><div><br></div><div>Be careful not to break that code <a href="https://stackoverflow.com/questions/5508110/why-is-this-program-erroneously-rejected-by-three-c-compilers" target="_blank">https://stackoverflow.com/questions/5508110/why-is-this-program-erroneously-rejected-by-three-c-compilers</a></div><div>More seriously i think it would be beneficial (necessary even) to have a source character encoding / character repertoire.</div><div><br></div><div><br></div><div>I wonder if we could specified that the internal character repertoire is Unicode. It kinda has to be already make that clearer.</div><div><br></div><div><br></div><div>I would also propose</div><div><br></div><div>Universal Character Name -&gt; Unicode Code point<br></div><div>(character name should be reserved to the \N proposal)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><blockquote type="cite"><div dir="ltr">
        <br>
        * Current terms, with what I think the actual meanings are
        today.<br>
        <br>
        <br>
      </div>
    </blockquote>
    <p>I think these are good.  With these, there is no need for a term
      like &quot;execution encoding&quot;, correct?  At compile-time, &quot;literal
      encoding&quot; encodes &quot;execution character set&quot; characters, and at
      run-time, &quot;dynamic encoding&quot; encodes &quot;extended character set&quot;
      characters, yes?</p></div></blockquote><div>I prefer &quot;execution&quot; to dynamic</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    <p>I like that this doesn&#39;t stray far from the existing terms.<br>
    </p>
    <p>Tom.<br>
    </p>
  </div>

_______________________________________________<br>
SG16 Unicode mailing list<br>
<a href="mailto:Unicode@isocpp.open-std.org" target="_blank">Unicode@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/unicode" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/unicode</a><br>
</blockquote></div></div>
</blockquote></div>