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@lists.isocpp.org> wrote:


On Fri, Feb 3, 2023 at 1:22 PM Jens Maurer <jens.maurer@gmx.net> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16