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

> On 4/27/21 1:56 PM, Corentin Jabot wrote:
>
>
>
> 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?
>
> I want the answer to be yes, that they should behave consistently, but I
> acknowledge this is more complicated. For example, a programmer may intend
> to format text in the locale encoding regardless of whether the literal
> encoding is UTF-8 or not. In that scenario, there is an implication that
> the format string be limited to characters that are valid for the locale
> encoding. On the other hand, the programmer may intend to produce UTF-8
> text and be quite surprised when std::format() inserts codepage 932 text
> in their output (regardless of whether their format string contains
> explicitly locale dependent field specifiers).
>
> This ambiguity is why I continue to have reservations about basing
> behavior (other than the encoded values of literals) on the compile-time
> literal encoding.
>

First of, I'm sorry for the miscommunication issue.
I think I understand you better now.

I think this is a good motivation to make the default behavior local
independant. I am really concerned. of the timeline here....
Then I think we should be vigilant not to try to shoehorn locales "fixes"
onto std::print.
But converting locale things _to_ utf-8 seems...okay.
It certainly doesn't make things worse!

An important point to keep in mind is: how do we evolve that thing :)

But again,

Tom.
>
> Tom.
>>
>>
>>
>