On Sat, Jun 11, 2022 at 11:55 AM Corentin <corentin.jabot_at_[hidden]> wrote:

> We had previous discussions in SG16 and conversation with Hubert (who is
> the main stakeholder) where we all agreed that the final wording we want is
> "characters are mapped, in an implementation-defined manner, to a sequence
> of translation character set elements."
> Whether we do this in this paper or the other, I fundamentally do not care
> as long as we land on that wording.
>
> "end-of-line indicators" is an ill-defined term that was meant to cover
> the record case specifically , but the reformulation does that as well.
>

"End-of-line indicator" is no less well-defined than "file" - it's a
reference to a common concept that is not otherwise defined by this
standard. If the objection is to the word "indicator," I'd be happy with a
formulation like "ends of lines are represented..."

The P2348 phrasing sweeps too much under the carpet. In fact, it gives the
impression that only characters present in the input file can be
represented in the result, which is not the case with the record-oriented
file representation.

I'd be okay with making this a note, since it's attempting to constrain
implementation-defined behavior, which is sort of suspect, but I think the
expectation that you get new-lines for end-of-records needs to be explicit
and not just assumed.

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