C++ Logo

sg16

Advanced search

Re: [isocpp-core] P2295 Support for UTF-8 as a portable source file encoding

From: William M. (Mike) Miller <"William>
Date: Sat, 11 Jun 2022 11:24:36 -0400
On Sat, Jun 11, 2022 at 10:59 AM Corentin <corentin.jabot_at_[hidden]> wrote:

>
>
> On Sat, Jun 11, 2022 at 4:52 PM William M. (Mike) Miller <
> william.m.miller_at_[hidden]> wrote:
>
>> On Sat, Jun 11, 2022 at 4:01 AM Corentin <corentin.jabot_at_[hidden]>
>> wrote:
>>
> My second comment regards new-line characters and end-of-line indicators.
>> As I understand it, there are two real-world scenarios the existing wording
>> is intended to cover: cases where different characters or sequences (CR,
>> CRLF) are used instead of new-lines, and record-oriented files where there
>> is no character at the end of a line. The word "introducing" is appropriate
>> for the latter case, but it seems incongruous for the former. Could we
>> replace that phrase with "representing end-of-line indicators as new-line
>> characters"?
>>
>
> This is preexisting and better addressed when we process P2348 Whitespaces
> Wording Revamp which addresses that point.
>

I think it is arguably more germane to this paper than that one. This paper
deals directly with the Phase 1 mapping of input source to the logical
source representation, and putting new-lines into the stream is part of
that process. P2348 deals principally with the post-Phase-1 treatment of
white space. I'd prefer to get Phase 1 clearly specified in this paper and
make only small tweaks (like renaming new-line to line-break) to Phase 1 in
P2348. (I don't want to get into a discussion of that paper in this thread,
but I strongly prefer the rewording I suggested above to the treatment of
the point in P2348, which is another reason I'd like to make the change
here.)

-- 
William M. (Mike) Miller | Edison Design Group
william.m.miller_at_[hidden]

Received on 2022-06-11 15:24:47