On Sat, Jun 11, 2022 at 11:55 AM Corentin <corentin.jabot@gmail.com> 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