C++ Logo

SG16

Advanced search

Subject: Re: Agenda for the 2021-07-14 SG16 telecon
From: Hubert Tong (hubert.reinterpretcast_at_[hidden])
Date: 2021-07-11 14:08:51


On Sun, Jul 11, 2021 at 12:56 PM Corentin Jabot <corentinjabot_at_[hidden]>
wrote:

>
>>
>>
>> In the third paragraph of phase 1:
>> [ ... ], then the physical source file shall be a well-formed UTF-8
>> sequence.
>> Each UCS scalar value encoded in the UTF-8 sequence is mapped to the
>> corresponding element of the translation character set.
>>
>
Just to clarify: I am suggesting the above for the wording (it was not
merely a quote providing context for the later comment). This version
separates the diagnostic requirement from the description of the processing.

>
>> I'm not sure what to make of the situation around end-of-line indicators
>> yet. P2348, "Whitespaces Wording Revamp", is also floating in the mix.
>>
>
> Indeed. P2348 is motivated by P2295.
> I believe it's not dramatic to leave things partially hanging (there can
> be line feed in utf-8 files and we do say that line feed is new-line in
> P2314), but I hope we will talk about P2348 at some point.
>

For the UTF-8 case, I think a note to the effect that "there are no
end-of-line indicators apart from the content of the UTF-8 sequence" could
help (at least to further the discussion). For P2348, I suggest that
"out-of-band" end-of-line indicators should remain accepted.

Suggestion for P2348:
The physical source file is mapped, in an implementation-defined manner, to
a sequence of basic source character set elements.

> Thanks,
> Corentin
>



SG16 list run by sg16-owner@lists.isocpp.org