On Thu, Sep 9, 2021 at 3:52 AM Corentin <corentin.jabot_at_[hidden]> wrote:

>
>
> 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
>

How about:
Physical source file characters are mapped, in an implementation-defined
manner, to the translation character set (introducing new-line characters
for end-of-line indicators).
=>
The physical source file is mapped, in an implementation-defined manner, to
a sequence of translation character set elements.


>
>> 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.
>

This is neither necessary nor harmless. The term "preprocessing directive"
is defined right after the grammar in [cpp.pre]. Its definition precludes
the presence of line-breaks outside of /**/ between preprocessing tokens
within the directive. We do want to allow comments in preprocessing
directives.

This seems to point to another problem with the wording:
(3)
The removal of the comment replacement in phase 3 means that the definition
of preprocessing directives requires an update to qualify that it wants to
talk about line-breaks (but not those that are inside /**/ comments).


>
> If people think that avoids confusion.
>
>
>