On 5/31/20 6:44 PM, Corentin via SG16 wrote:

L'ab' currently has an implementation defined value
GCC, MSVC and Clang treats that value to be equivalent to L'a' and emit a warning

However,  consider

L'é' which after phase one is represented as L'e\u00B4' (LATIN SMALL LETTER E, ACUTE ACCENT).

The author of the code probably intends the character to be a single c-char.

Therefore,  I think this should be made ill-formed.

Note that this is less of an issue for multi character literals as no combining character has a representation in any single-byte encoding (that I know of). 
(And multi character literals, are, to my dismay, used in production code).

However we should probably require that each individual c-char in a multi character literal has a representation in the execution encoding or is a member of the basic latin block.

What do you think ?

[lex.ccon]p1 already specifies that the ordinary (non-wide) form of these cases is conditionally-supported, so need not be implemented.

... 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.
Similar wording doesn't exist for the wide variants, but I've taken the perspective that the omission is an oversight.  P2029 specifies wording changes intended to clarify that the wide variants are also conditionally-supported.

Since the wide character set is implementation-defined, I don't think we should attempt to make L'é' ill-formed, regardless of any Unicode normalization concerns.  If the implementation-defined wide character set is able to represent the specified character in a single code unit, I think that is ok and that there is little motivation to break existing code.

I'm in favor of updating wording for wide character and string literals to better specify them and to better reflect existing practice, but I'm not in favor of investing time improving or changing their behavior otherwise.