My thanks to the author for addressing the feedback given on r0. I now have feedback (below) on r1.
-- HT
I believe the author is already aware that the comment grammar should be corrected to indicate a sequence of characters within the comment.
I believe similarly with regards to objections to using the grammar term in prose.
As noted in the SG 16 meeting today, the paper removes the freedom for an implementation to consider a preprocessing directive containing vertical tab or form feed as being an error. This is a design decision that the paper does not acknowledge as such. I believe that noting this change clearly in the paper's design section is sufficient to remedy this.
I have the following additional concerns about the wording:
(1)
In [lex.phases],
"introducing new-line characters for end-of-line indicators"
is removed.
I do not believe that this is helpful. The presumed intent remains that implementations may introduce line-breaks of one form or another for end-of-line indicators that do not correspond particularly to any "physical source file character".
I do not believe the existing wording is helpful either. "implementation-defined mapping" lets implementers add any codepoint for any reason, dataset being one of them. My issue with that wording, is that i find it confusing. "end-of-line-indicator" not being defined anywhere.
If we think this use case is sufficiently important to be called out explicitly, would you be amenable to, for example, a footnote?
[Footnote: If the physical source file is a set of records, implementation may introduce line breaks to denote the end of records] - or something along those lines
Note that [cpp.line] contains a reference ("or introduced") to this text.
(2)
In the new [lex.whitespaces] subclause, the following is added:
whitespaces are ignored except as they serve to separate tokens
This seems to have come from the text being removed out of [lex.token] (where it was excusable). Whitespace separation is significant in [cpp.replace.general], etc. This sentence should at best be a note in relation to phase 7 of translation.
I am happy to remove it entirely.
It's certainly not needed for phase 7. And I think phase 3 wording says something similar.
In [cpp.pre], Jens objected to my removal of
> The only whitespace characters that shall appear between preprocessing tokens within a
preprocessing directive (from just after the directive-introducing token through just before
the terminating new-line character) are space and horizontal-tab (including spaces that have
replaced comments or possibly other whitespace characters in translation phase 3).
I am not able to convince myself than the grammar described at the start at [cpp.pre] allows line-breaks to appear between preprocessing tokens within a preprocessing directive,
but I'm happy to replaced the striked paragraph by
Only horizontal-whitespaces shall appear between preprocessing tokens within a preprocessing directive.
If people think that avoids confusion.