Full name of submitter (unless configured in github; will be published with the issue): Jim X

The original issue is cplusplus/draft#5247

[lex.ccon] p1 says

A non-encodable character literal is a character-literal whose c-char-sequence consists of a single c-char that is not a numeric-escape-sequence and that specifies a character that either lacks representation in the literal's associated character encoding or that cannot be encoded as a single code unit.

[lex.charset] p8 only says

A code unit is an integer value of character type ([basic.fundamental]).

So, what is the type of a single code unit for ordinary character literal, wide character literal, UTF-8 character literal, UTF-16 character literal, UTF-32 character literal? We didn't clearly specify them. The coloum Type in the table just specify what the type of the character literal is.

The kind of a character-literal, its type, and its associated character encoding ([lex.charset]) are determined by its encoding-prefix and its c-char-sequence as defined by Table 9.

We didn't specify what the type of a single code unit for the corresponding literal is, then we cannot determine what the range of the representable values of a single code unit is, that is, we cannot determine whether a character can be encoded in a single code unit or not for that character-literal.

Similarly, we didn't specify what the type of a single code unit for a string-literal is. At best, [lex.string] p10 can barely imply the single code unit's type is relevant to the element type of the string-literal.

String literal objects are initialized with the sequence of code unit values corresponding to the string-literal's sequence...

Because the string literal object is of type array of n T, since the array is initialized by the sequence of code unit, that is, the element corresponds to a code unit, which may imply that the element type is relevant to the type of a single code unit in the string-literal. There is an exception to the ordinary string literal, assume it uses utf-8 encoding

const char* ptr = "Õ";

The sequence of the code unit values will be {195, 149, 0 }. Both 195 and 149 cannot be represented in the type char if we assume char is signed char with width 8. If the array object is initialized with this sequence, there is narrow conversions, which cause the program ill-formed.

Anyway, we don't have any implication wording for character-literal.

Suggested Resolution

Presumably, the unsigned version of the Type column in the table should also be the type of the single code unit for that character-literal, and the unsigned version of the element type of a string-literral should also be the single code unit for that string-literral, we should clearly specify the type of a single code unit for the character-literal and string-literal.