[byte.string] Footnote 131 is not entirely accurate

[AlisdairM]

Footnote 131, attached to [byte.string]p4, states:

131. A string-literal, such as "abc", is a static NTBS.

In practice, we might mean a plain-string-literal as that removes the potential encoding-prefix. However, plain-string-literal is a lexical part of the grammar, and it is only the full string-literal grammar that is associated with an object.

Perversely, since we added the ability to include named unicode code points in string literals by use of named-universal-characters, there is no guarantee that even a plain-string-literal would be a static NTBS unless we restrict its contents to the basic literal character set (as we guarantee each member of the basic literal character set can be encoded in a single byte).

As this is just a footnote we might not care that we are not precise, and the specific cited example is correct. However the note does seem over-generalized, and we could weaken to say that "some" string literals are ..., or "often" string literals are ...

Alternatively, we might consider the footnote more trouble than is worth correcting, as just strike the footnote? Or maybe move a more precise [Note: ... --- end note] into the main text?

I am happy to work on a resolution, if we have an agreed preference for how to proceed.
We could also close this issue as NAD if we think there is nothing to correct.

[jensmaurer]

I disagree with your analysis. An NTBS is defined in [byte.strings] p1 as a "character sequence" (what does this mean?) with a terminating 0. And that's true even for prefixed string literals; encodings must not have a 0 code unit value except for the \0 terminator; see [lex.charset] p5 "The u+0000 null character is encoded as the value 0. No other element of the translation character set is encoded with a code unit of value 0."

[AlisdairM]

The term "character sequence" is defined in the preceding clause, [character.seq.generalp(1.5):

| A character sequence is an array object (10.3.4.5) A that can be declared as T A[N],
| where T is any of the types char, unsigned char, or signed char (7.11.2), optionally
| qualified by any combination of const or volatile.

Hence, the only valid string-literals for an NTBS are plain-string-literals without an encoding-prefix.

The second point about excluding code points that require multiple code units is inferred from the definition of NTMBS that allows for multibyte characters. It could be that the library wording itself needs clarification here, via a LWG issue, before my second claim about the footnote can be substantiated?

[AlisdairM]

Perhaps also relevant is that in addition to the null terminator having the code point 0, [lex.charset]p5 guarantees that elements of the basic literal character set are expressed as a single code unit in a literal encoding.

| A literal encoding ... encodes each element of the basic literal character set as
| a single code unit with non-negative value, distinct from the code unit for any other
| such element.

[jensmaurer]

Ok.

In order to retain at least some of the contents here, I think we should move the footnote in question to an inline example:
[Example: The string-literal "abc" (lex.string) is a static NTBS. --- end example]

The other two footnotes on that same page should move to inline notes, btw. (separate pull request)