[cpp.line] Address string-literal vs s-char-sequence #8369
Conversation
The text of this specification places a restriction on a string-literal that is not present in the grammar, although the grammar is an exact match for a string-literal with that restriction. The restricted term is also used when specifying the effects of the line directive with a string, so prefer to move string-literal into the grammar rather than strike that paragraph and adjust the effects. Added a cross-reference to where character string literal is defined as it may not be obvious to all readers that this is a term of power, even though it is defined as a term and has an index entry.
AlisdairM
changed the title
source/preprocessor.tex
Outdated
| A preprocessing directive of the form | ||
| \begin{ncsimplebnf} | ||
| \terminal{\# line} digit-sequence \terminal{"} \opt{s-char-sequence} \terminal{"} new-line | ||
| \terminal{\# line} digit-sequence \terminal{"} \opt{string-literal} \terminal{"} new-line |
There was a problem hiding this comment.
No.
First, a string-literal includes the delimiting quotation marks, so this is a bad change.
Second, a string-literal allows for an encoding-prefix or rawness, but the status quo "form" match does not. So, this is a bad change, because it would appear to allow such prefixes (and we don't know what they mean in this context). A reference to "the character string literal" does not establish a suitable constraint.
Yes, p1 talks about a string-literal with zero context, and that's a bug that needs to be fixed, but this intro sentence is at issue, not the rest of the specification without further elaboration. What does C23 say in that area?
There was a problem hiding this comment.
The term "character string literal" is a well defined term establishing exactly that restriction, but if you prefer I will tackle this problem from the specification of what to do with the s-char-sequence instead.
My preferred resolution for C++29 would be to introduce character-string-literal as the quoted s-char-sequence in [lex.string], so that a string-literal is an encoding prefix followed by either a character-string-literal or a R raw-string-literal. That would allow us to use character-string-literal both here in [cpp.line] and [cpp.stringize], and potentially clean up other parts of the standard jumping around string literal syntax --- but that is more than I want to push into ballot review time, as that would clearly need Core review, better spent elsewhere.
|
CWG2693 is related. |
|
And see CWG3076 for the introduction of plain-string-literal (with no prefix), which might be useful here. But that's not editorial territory; there is too much subtlety to go wrong. |
|
I have pushed a revision with the basis of my broader update, and will turn this into a draft PR. I suspect that my update will be in the direction of plain-string-literal but I think you cited the wrong core issue? Noted that the direction specifically for I will leave this now as potential C++29 material. |
There are several places in the grammar where we want to refer to a plain character string literal without a prefix and that is not raw. Introduce _character-string_ into the grammar to replace a quoted _s-char-sequence_in a number of places, and move the `R` of a raw string literal into the _raw-string_ grammar so that _raw-string_ and _character-string_ are used consistently where they appear.
AlisdairM
force-pushed
the
fix_string_literal_in_line_directive
branch
from
104160f to
d74f45a
Compare
2 participants
The text of this specification places a restriction on a string-literal that is not present in the grammar, although the grammar is an exact match for a string-literal with that restriction.
The restricted term is also used when specifying the effects of the line directive with a string, so prefer to move string-literal into the grammar rather than strike that paragraph and adjust the specification for its effects.
Added a cross-reference to where character string literal is defined as it may not be obvious to all readers that this is a term of power, even though it is defined as a term and has an index entry.