On 29/10/2021 04.53, Hubert Tong via SG16 wrote:
> Thanks Corentin for the paper. I hope this feedback helps the discussion.
>
> With respect to the contents of multicharacter literals, the paper does not give much motivation for disallowing numeric escape sequences which fit within a single unsigned char. Also, the wording says "shall be a member of the basic literal character set": this property of "being" is rather ambiguous in terms of authorial intent regarding the treatment of UCNs, etc. that designate members of the basic literal character set (a name for something is usually not the same as the thing it names).

I agree that the restriction

"Each c-char in a multicharacter literal shall be a member of the basic literal character set."

is novel and should just go.

(Why would the use of "@" or "$" be particularly bad in a multicharacter literal?)

> With respect to the new encodability restriction for strings, I believe that unevaluated strings should not be treated the same way as strings that need to be translated into a literal encoding. I think we may need to advance P2361 ("Unevaluated strings") first.

The paragraph in question starts with
"String literal objects are initialized with the sequence of code unit values..."

The existing text using /string-literal/ in various places makes it clear when
and if a string-literal is converted to a string literal object.
Insofar, I consider P2361 superfluous.

Jens