On Thu, Sep 9, 2021 at 1:30 AM Hubert Tong <hubert.reinterpretcast_at_[hidden]>
wrote:

> 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-whitespace*s shall appear between preprocessing tokens
within a preprocessing directive.

If people think that avoids confusion.