On 2/4/23 9:35 AM, Corentin Jabot via SG16 wrote:
> What Steve said.
> Per popular request I added some text in the paper
> https://isocpp.org/files/papers/P2741R1.pdf

Thank you, Corentin. That additional analysis is quite helpful.

Tom.

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