On Tue, Apr 27, 2021 at 7:20 PM Tom Honermann <tom_at_[hidden]> wrote:

> On 4/27/21 12:27 PM, Corentin Jabot wrote:
>
>
> I think we've been focusing on different things here. The issue I'm
>>> trying to discuss is independent of use of the
>>> write-directly-to-the-console method. This discussion is about having
>>> std::print() (and std::format()) internally ensure that that format
>>> arguments provided by the locale are transcoded to match the encoding of
>>> the format string. This happens before anything is written to the console;
>>> this is the step where the formatting is done and the intent is to ensure
>>> that well-formed text is produced *before* it is transcoded to the native
>>> console encoding (whether that be UTF-8, UTF-16, whatever). Transcoding
>>> requires well-formed input of course.
>>>
>>> Does this help to get us on the same page
>>>
>>
> I actually disagree with that.
> I don't think there is intent in the current design that the output has to
> be text at all. I could use format to create some kind of binary format if
> i wanted to, except the _formatting_ string is text because it needs to be
> parsed,
> So format as specified doesn't put requirements on the arguments
> beyond the formatting string and doesn't need to.
> What makes print text is that it outputs to the console, at which point
> text is assumed.
> The transcoding happens after formating, and might as well not
>
> forrmat(a, b, c) -> result
> printUtf8ToConsole(result);
>
> The fact that printUtf8 is implemented as printUTF16(toUTF16(result)) is
> an implementation detail that should not be observable nor described by the
> C++ standard.
>
> And I don't think print should do _anything_ to check for some amount of
> validity before printing out something.
>
> I don't disagree with what you wrote above, but it is not relevant to this
> discussion. I don't know why we're having such a hard time communicating
> here. Please, carefully re-read some of my prior responses with the
> understanding that how you have understood them so far does not match what
> I intended. If you then have clarifying questions, please feel free to ask
> them.
>

Okay, so your point is that implementations should do something magical for
things that are formatted through a locale facet on the basis the encoding
of the result of time_put is known?


> Tom.
>