On 2/3/23 11:28 PM, Steve Downey via SG16 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."

SG16 established consensus during its 2021-01-13 telecon
<https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2021.md#january-13th-2021>
discussion of P2246 (Character encoding of diagnostic text)
<https://wg21.link/p2246> that diagnostic presentation of source code
fragments is a QoI concern and, with the adoption of that paper, the
standard consistently specifies normative guidance that implementations
"should include" the relevant source text (see [dcl.pre]p10
<http://eel.is/c++draft/dcl.dcl#dcl.pre-10>, [dcl.attr.deprecated]p4
<http://eel.is/c++draft/dcl.attr.deprecated#4>, [dcl.attr.nodiscard]p4
<http://eel.is/c++draft/dcl.attr.nodiscard#4>, and [cpp.error]p1
<http://eel.is/c++draft/cpp.error#1>) without further requirements. I
think we're all aligned with being very hand wavy in this respect.

But what about the requirements on text passed to static_assert() where
the text is generated (in constant evaluation context; not a
string-literal)? Are you suggesting there is no need to specify a
well-defined encoding, even an implementation-defined one, for the
static_assert() declaration? See my initial reply to the top of the
thread with more detail.

Tom.

>
>
> 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
>
>