Subject: Re: [isocpp-core] New draft revision: D2029R2 (Proposed resolution for core issues 411, 1656, and 2333; numeric and universal character escapes in character and string literals)
From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2020-07-03 02:11:55
On 02/07/2020 18.43, Tom Honermann via SG16 wrote:
> On 7/2/20 3:15 AM, Corentin via Core wrote:
>> literal encoding is a less ambiguous term either way.
>> We needÂ a terminology such that we can distinguishÂ the encoding of literals from that of runtime strings, literal (associated) encoding achieves that.
> Ah, I think we may be crossing hairs here.Â I agree that we should have an abstract name that indicates the encoding used for literals.Â We lack a term for that today (which is why the paper uses the phrase "encoding of the execution character set").Â But that is different from what is intended by "associated character encoding"; this is intended to name an encoding (possibly indirectly, hence "encoding of the ...") that might be registered with IANA <https://www.iana.org/assignments/character-sets/character-sets.xhtml> (where the term "character set" is used to mean "character encoding", but the former is used for legacy reasons).
You lost me there.
What does IANA's list of character sets/encodings have to do with
how a compiler chooses to encode C++ literals?
Maybe the compiler has invented an encoding of its own, just
for the fun of it.
If you intend some stronger relationship to IANA here, this
needs to be a lot of explicit.
SG16 list run by email@example.com