<div dir="ltr"><a href="https://isocpp.org/files/papers/P1859R0.html">https://isocpp.org/files/papers/P1859R0.html</a> is my attempt at disentangling the wording around character sets and encodings. Since the values of literals are self-evidently fixed at translation time, any interpretation that involves changing the values of a literal based on the current locale does not make sense. I believe that the intent of lex.charset/3 was to use the locale specified for the compiler to produce the values of literals when encoding from the internal representation of characters. I'm asking that that be termed "{narrow,wide} literal encoding", as opposed the the "dynamic encoding" controlled by the conversion facet of the currently set locale. <br><br>The interpretation in the standard seems to vary considerably. Fortunately there is not, I believe, implementation divergence. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 4, 2019 at 9:33 AM Jean-Marc Bourguet <<a href="mailto:jm@bourguet.org">jm@bourguet.org</a>> 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">On 04.11.2019 09:45, Tom Honermann wrote:<br>
> On 11/4/19 7:18 AM, Howard Hinnant wrote:<br>
>> On Nov 4, 2019, at 12:27 AM, Tom Honermann <<a href="mailto:tom@honermann.net" target="_blank">tom@honermann.net</a>> wrote:<br>
>>> I suggest the following wording: (using terminology from P1859R0)<br>
>>> <br>
>>> If Period::type is micro, but the character U+00B5 <del>cannot be <br>
>>> represented in the encoding used</del><ins>lacks representation in <br>
>>> the execution character set</ins> for charT, the unit suffix "us" is <br>
>>> used instead of "μs". <ins>If<br>
>>> "μs" is used but the dynamic encoding lacks representation for U+00B5 <br>
>>> and the stream is associated with a terminal or console, or if the <br>
>>> stream is imbued with a std::codecvt facet that lacks conversion <br>
>>> support for the character, then the result is unspecified.</ins><br>
>>> <br>
>> I’ve no objection to an issue, but your proposed wording explicitly <br>
>> involves two things I’m strongly against:<br>
>> <br>
>> 1. Now the code has to check the locale, for this precision only.<br>
>> <br>
>> 2. Now the code has different behavior between cout and <br>
>> ostringstream. And the result of ostringstream is very commonly <br>
>> subsequently sent to cout (ostringstream is a common formatting aid).<br>
>> <br>
>> Imo, the proposed wording is much, much worse than the status-quo and <br>
>> I would vote strongly against it.<br>
> <br>
> No, the wording I proposed doesn't check for locale. The execution<br>
> character set is the character set used for string literals and is <br>
> known<br>
> at compile time; it is not the locale dependent run-time character set.<br>
<br>
lex.charset/3 states<br>
<br>
The values of the members of the execution character sets and the <br>
sets of additional members are locale-specific.<br>
<br>
apparently making the execution character sets run-time dependent.<br>
<br>
But lex.ccon/2 states<br>
<br>
An ordinary character literal that contains a single c-char <br>
representable in the execution character set has type char, with value <br>
equal to the numerical value of the encoding of the c-char in the <br>
execution character set.<br>
<br>
apparently making it fixed.<br>
<br>
I've not looked at that more in-depth to see which interpretation is the <br>
more pervasive.<br>
<br>
Yours,<br>
<br>
-- Jean-Marc Bourguet<br>
_______________________________________________<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>