This is one of two SG16 mailing list reviews that I plan to conduct this
week.

LEWG will be discussing this paper in their telecon *tomorrow*. Please
respond to this poll today if possible, especially if you are of the
opinion that there are SG16 related concerns that are not adequately
addressed or discussed in the paper.

*Poll: Forward P2758R4 <https://wg21.link/p2758r4> (Emitting messages at
compile time) to LEWG*

Please respond with +1 if you are in favor of the poll and -1 if you
believe this paper needs further review in an SG16 meeting in which
case, please also summarize your concerns.

Note that a +1 response does not indicate that you approve of the paper;
it only indicates that you believe the paper adequately addresses and/or
represents SG16 related concerns, either in the proposed design itself
or in prose that adequately describes such concerns and the options for
addressing them. The goal is to ensure the paper presents sufficient
information for LEWG to make a well informed decision.

SG16 previously reviewed P2758R2 <https://wg21.link/p2758r2> during its
2024-04-10 meeting
<https://github.com/sg16-unicode/sg16-meetings#april-10th-2024>.
Concerns raised during that discussion included:

  * Updates are needed to reflect the adoption of P2741R3
    (user-generated static_assert messages) <https://wg21.link/p2741r3>.
    This was done for P2758R3 <https://wg21.link/p2758r3>.
  * Wording updates are needed to specify character encoding
    requirements. This was done for P2758R3 <https://wg21.link/p2758r3>;
    see the proposed wording for [meta.const.eval]p2. *There should
    probably be similar wording for tag names.*
  * Wording updates are needed to specify conformance requirements in
    [intro.compliance.general]
    <http://eel.is/c++draft/intro.compliance.general>. This was done for
    P2758R3 <https://wg21.link/p2758r3>, but then P2758R4
    <https://wg21.link/p2758r4> went in a different direction; see the
    wording updates to [basic.start.static].
  * Updates are needed to constrain what characters may appear in tag
    names and such constraints should exclude characters that have
    special meaning in common command line environments. This was done
    for P2758R3 <https://wg21.link/p2758r3>; tag names are limited to
    /nondigit/ <https://eel.is/c++draft/lex.name#nt:nondigit>, /digit
    <https://eel.is/c++draft/lex.name#nt:digit>/, and '-'; see the
    proposed wording for [meta.const.eval]p5. *However, these
    restrictions appear to be missing for constexpr_warning_str() and
    constexpr_error_str()*.
  * All of the proposed functions should support tags to enable
    suppression. This was done for P2758R3 <https://wg21.link/p2758r3>;
    constexpr_print_str() may optionally be called without a tag while
    the others require a tag.
  * Handling of escape sequences needs more specification. *This does
    not appear to have been addressed.*
  * A portable means to suppress false positives is needed. This concern
    remains unaddressed, but is more of a LEWG concern than an SG16 one.

Barry, per the analysis above, it looks like some wording level
corrections or adjustments are needed.

Tom.