Wording nits:

There is no such thing as “compile time” in the standard. Suggest p1 of the new clause be:

> The facilities in this subclause are used to emit messages during program translation.

The wording requiring that messages appear in diagnostics is stronger than we have for core-language facilities such as `static_assert`. Use of the message in the emitted diagnostic should be downgraded to a Recommended practice.

I have design concerns about the wording of the Recommended practice for implementations to opt in or out of warnings based on the tag-string value, but that is more a question of specification style than intent, so can be deferred to LEWG/LWG discussion.


I would forward to LEWG if the requirements on including the exact messages in diagnostic text were changed to recommended practice. The rest can be picked up in wording. I would need to be sold on forwarding as-is.

AlisdairM

> On Jan 27, 2025, at 1: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().
> 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.
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16