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
>