On Sun, 8 Sep 2019 at 05:46, Tom Honermann <tom@honermann.net> wrote:
On 9/5/19 9:41 PM, Steve Downey wrote:
Because I needed to circulate what I'm doing for Belfast, I've thrown together an abstract for the paper we've peripherally discussed about modernizing and tightening the specification around encodings of characters generally, and the source and execution character sets. 

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.

I'm hoping to have some preliminary work by the next telecon. The direction I'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'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.
This all sounds great.  My only question is behavior being unspecified vs undefined.  It seems challenging to get away with making it only unspecified.

Specifically, I'd like something along the line of:
If a character literal contains a c-char that do not have the same representation in the character literal encoding (aka *presumed" execution encoding) and the execution encoding, the behavior is undefined.


Some possible terms:
{"",Narrow,Wide} Literal Encoding - encoding on char and string literals
Dynamic Encoding - encoding implied by locale
*Character Set - A set of abstract characters ( Latin Capital letter A, Digit Zero, Left Parenthesis ...)
Unicode uses "character repertoire" for abstract sets of characters.  I favor following suit there.

+1 to sticking to Unicode terms 
*Basic Character Set - minimum required to be encoded
*Extended Character Set - what can be encoded
*Source Character Set - must be encodable in C++ source
I don't think "source character set" is defined today.  The closest we get is "Physical source file characters" in [lex.phases]p1.
*Execution Character Set - Source + control characters

Be careful not to break that code https://stackoverflow.com/questions/5508110/why-is-this-program-erroneously-rejected-by-three-c-compilers
More seriously i think it would be beneficial (necessary even) to have a source character encoding / character repertoire.

I wonder if we could specified that the internal character repertoire is Unicode. It kinda has to be already make that clearer.

I would also propose

Universal Character Name -> Unicode Code point
(character name should be reserved to the \N proposal)

* Current terms, with what I think the actual meanings are today.

I think these are good.  With these, there is no need for a term like "execution encoding", correct?  At compile-time, "literal encoding" encodes "execution character set" characters, and at run-time, "dynamic encoding" encodes "extended character set" characters, yes?

I prefer "execution" to dynamic

I like that this doesn't stray far from the existing terms.


SG16 Unicode mailing list