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

> On Wed, Sep 22, 2021 at 3:07 PM Corentin <corentin.jabot_at_[hidden]> wrote:
>
>>
>>
>> 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
>>
>
> Yes it does. Might be mildly better if "results in a new-line in the
> resulting execution string" is replaced with "denotes a new-line" since
> "denotes" is used elsewhere in [lex.string] to refer to what a string
> means. Note that this does also mean that all *line-break*s within a raw
> string behave the same as "\n" in a non-raw string even for unevaluated
> strings.
>

Done, Thanks https://isocpp.org/files/papers/D2348R2.pdf