On Wed, Sep 22, 2021 at 6:11 PM Hubert Tong <
hubert.reinterpretcast_at_[hidden]> wrote:

> On Wed, Sep 22, 2021 at 11:46 AM Corentin <corentin.jabot_at_[hidden]>
> wrote:
>
>>
>>
>>>
>>>>
>>>>>
>>>>> The [lex.string], the "*line-break*" in a raw string literal wording
>>>>> could be more explicit about scanning for line-breaks (sequences matching a
>>>>> *line-break* is not a *line-break* "for free"; it is a *line-break*
>>>>> if, for example, the grammar asks for a *line-break*).
>>>>> This can be done by adding *line-break* under the *r-char* grammar
>>>>> and adjusting the other *r-char* case with the formula from
>>>>> *single-line-comment-elem*.
>>>>>
>>>>
>>>> I am not sure I agree with all of that, but I do agree that there isn't
>>>> no line-break as such in a raw string literals.
>>>> I've replaced it with " A sequence of characters that matches the
>>>> grammar of line-break ..."
>>>>
>>>
>>> That approach is fine. Still need to watch out for the CRLF versus CR +
>>> LF ambiguity.
>>>
>>
>> I added "A whitespace is the longest sequence of characters that could
>> constitute a whitespace." in [lex.whitespace]. I believe this is true for
>> all sort of whitespaces, including comments and
>> it takes care of both line-breaks and comments
>>
>
> It takes care of *line-break*s that are whitespace. It does not take care
> of *line-break* matching that bypasses the *whitespace* grammar term
> (like in raw strings). The second copy of the sentence with *link-break*
> in place of *whitespace* would work.
>

I went with "Each longest sequence of characters that matches the grammar
of a line-break in a raw string literal results in a new-line in the
resulting execution string
literal". I hope that addresses your comment