On Thu, Jul 13, 2023 at 5:56 PM Steve Downey <sdowney_at_[hidden]> wrote:

>
>
> On Thu, Jul 13, 2023 at 9:49 AM Hubert Tong via SG16 <
> sg16_at_[hidden]> wrote:
>
>> On Thu, Jul 13, 2023 at 3:59 AM Corentin Jabot <corentinjabot_at_[hidden]>
>> wrote:
>>
>>> Hey Hubert, I sadly missed the last meeting, which I'm guessing provides
>>> some necessary context here.
>>>
>>
>> This was more of a concern I raised on the side that was not much
>> discussed in the meeting. I did fail to relay important context though: The
>> ordinary/wide string literal encodings are properties of the compilation
>> environment and there is no guarantee that the runtime environment has the
>> facilities necessary to programmatically decode those encodings (e.g.,
>> maybe literals in the program are only passed to fputs).
>>
>> The leakage of literal encoding information into the type system (at some
>> level or another) was also briefly mentioned. Related unspoken context is
>> that separately-compiled translation units (e.g., third-party library
>> packages) will potentially have different literal encodings. Strategies to
>> contain the ODR-violation fallout should be employed.
>>
>>
>>> I'll try to answer some of these things in a vacuum anyway, i like to
>>> live dangerously!
>>>
>>> Generally, I'd be rather concerned about the need to reason about
>>> literal encoding at runtime.
>>> Without a way to track in the type system whether a string was produced
>>> at runtime or at compile time (including those who are produced by constant
>>> evaluation),
>>>
>>
>> Treating runtime strings the same way as compile-time strings was (iirc)
>> part of the motivation for specifying interpretation using the literal
>> encoding in the first place. We don't need to differentiate between strings
>> produced at runtime versus compile-time for encoding purposes with the
>> current specification.
>>
>>
>
> It was more about trying to accurately describe the current situation than
> about any change. We have this ODR violation happening today, but now it's
> much easier to explain what has gone wrong, and place the blame on users
> trying to define string literals differently by having different literal
> encodings.
>
>
>
>> (which i think we actively do not want as, in addition of the added
>>> complexity, we, i think, prefer not have constant evaluation behave
>>> differently from the runtime),
>>> It seems generally impossible to do.
>>>
>>
>> [format.string.escaped] explicitly refers to the associated character
>> encoding for `charT`, with a reference to Table 12 (which documents literal
>> encodings). So reasoning about the literal encoding at runtime is necessary
>> with the current specification.
>>
>>
>
> And always has been, although we had no tools with which to do so.
>

I disagree. It was the user's job to ensure that their literals are passed
to things in the runtime environment that can handle them. If they pass
their literals to something that assumes the execution character set, then
they better make sure they use the right locale.

C++23 adds a new facility that requires, for good quality with multibyte
encodings, the C++ standard library to understand the literal encoding (in
part, in the way that `mbtowc` understands the execution encodings) at
runtime.


>
>
>>
>>>
>>>