+1
(All my remaining concerns are non-SG16)


On Mon, Jan 27, 2025 at 7:00 PM Tom Honermann via SG16 <
sg16_at_[hidden]> wrote:

> 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()*
> .
>
>
The restrictions are on the *tag-string* constructor, so they apply to
warning/error/print (It looks good as is)


>
> - 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.
>
> Regardless of my reservations there, this feels Non-SG16

>
> - Handling of escape sequences needs more specification. *This does
> not appear to have been addressed.*
>
> Meh. Should we want restrictions, they would be the same for static_assert,
and I tend to see it's purely QOI
https://compiler-explorer.com/z/nresK1qrd
<https://compiler-explorer.com/z/nresK1qrd>

>
> - 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.
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>