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

> On 4/27/21 1:43 PM, Corentin Jabot wrote:
>
>
>
> 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?
>
> Yes, with two minor caveats.
>
> 1. I don't see this as magical since the source and target encodings
> are known.
> 2. I'm only suggesting this as a design option for us to consider.
> I'm not claiming that I think this is the best approach to the problem (I'm
> undecided as to what solution I favor so far).
>
>
Another question: do you think format should have the same behavior?

> Tom.
>
>
>