What Steve said.
Per popular request I added some text in the paper
https://isocpp.org/files/papers/P2741R1.pdf

On Fri, Feb 3, 2023 at 8:29 PM Steve Downey via SG16 <sg16_at_[hidden]>
wrote:

> I'm strongly inclined to be very hand wavy here. Compilers are highly
> incentivised to do as good a job as they can, in an environment where
> they're entitled to expect some cooperation from the programmers involved.
> I don't think anyone really wants to introduce yet another encoding
> context, especially since that won't actually help in displaying the output
> of the compiler.
> My source code is in Shift-JIS, the literal encoding is GBK, my terminal
> locale is en_US.UTF-8, and although this is just a library translation unit
> main will call setlocale (LC_ALL, ""); , so compiler sort this out, well
> that is not actually possible.
>
> Best effort, and assume good faith. But there's no way to mandate that the
> 'é' in "Melniboné" is expressed to the user with the correct diacritic.
> We can't at runtime, either, even when we can make some guesses.
>
> Taking the static assert and related wording is very appropriate. Misusing
> a quote a bit, "Whereof one cannot speak, thereof one must be silent."
>
>
> On Fri, Feb 3, 2023 at 2:36 PM Barry Revzin via SG16 <
> sg16_at_[hidden]> wrote:
>
>>
>>
>> On Fri, Feb 3, 2023 at 1:22 PM Jens Maurer <jens.maurer_at_[hidden]> wrote:
>>
>>>
>>>
>>> On 03/02/2023 06.16, Tom Honermann via SG16 wrote:
>>> > SG16 currently has two papers in its queue that seek to allow code
>>> evaluated in constant expression context to produce text to be displayed to
>>> a (compiler) user at compile time.
>>> >
>>> > * P2741R0 <https://wg21.link/p2741r0>: user-generated static_assert
>>> messages
>>> > * P2758R0 <https://wg21.link/p2758r0>: Emitting messages at compile
>>> time
>>> >
>>> > JF is planning for EWG to review these in Issaquah. Since SG16 will
>>> not be meeting in Issaquah, our options are limited for providing
>>> recommendations prior to that initial EWG review. JF has asked that we
>>> conduct a review via mailing list to collect input prior to EWG's review.
>>> SG16 will still review post-Issaquah as we usually would in order to
>>> provide a recommendation for EWG to consider in a future telecon or in
>>> Varna.
>>> >
>>> > Please respond to this message with your thoughts on these papers
>>> before Monday, February 6th, if possible; I know that is short notice. I
>>> will plan to prepare a summary for EWG.
>>>
>>> I notice that the paper contains to discussion of encoding concerns
>>> at all.
>>>
>>> A phase 7 string literal evaluated in a constant expression is
>>> currently no different from such a string literal evaluated at
>>> runtime, conceptually: Both are converted to the literal encoding
>>> and considered as an array of integers, essentially.
>>>
>>> I think the question of what exactly we'd like an implementation
>>> to do with such compile-time string literals ending up in compiler
>>> diagnostics should be discussed in the paper.
>>>
>>> Thanks,
>>> Jens
>>>
>>
>> As I've noted in the past, I have no experience or domain knowledge in
>> anything related to encodings or any of these issues. I'm happy to defer to
>> whatever SG16 says is the right thing.
>>
>> However, Tom's suggestion that we only use charN_t types doesn't work I
>> think. std::format() returns a std::string so once we widen support for
>> messages from simply string literals (and we extend std::format to work in
>> constexpr), static_assert(cond, std::format("error")) needs to be valid.
>>
>> Barry
>> --
>> SG16 mailing list
>> SG16_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>