Date: Wed, 22 Sep 2021 16:21:43 -0400
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.
>
>
> 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.
Received on 2021-09-22 15:22:14