Thanks! FWIW, users do want this sort of capability, but the fact that
no implementation has yet to add a feature with bells and whistles is
because the problem is not easy to solve. I'm highly skeptical that
this is something WG21 should be standardizing at all currently; it's
firmly in the realm of QoI and different implementations have
different needs (and our needs evolve over time). The only form of the
feature I would consider supporting would be one that accepts the
message to be printed during constant evaluation and nothing else.
Anything with more bells and whistles will be problematic in practice.

Practical implementability problems include:
* Different implementations have different severities for diagnostics
(error, warning, note, remark, no severity distinctions, etc)
* Different implementations have different rules for additional
effects on diagnostics (default ignore, default error, SFINAE trap,
etc)
* Different implementations have different ways to identify
diagnostics (unique numeric identifier, warning group, no
identification at all, etc)
* Some implementations have the ability to group diagnostics together,
other implementations don't
* Some implementations localize their diagnostics, so trying to make
user-defined diagnostics look like compiler diagnostics can cause
consistency issues
* Not all diagnostics are emitted to a terminal (there may be
limitations on what can be emitted as a diagnostic depending on
whether the diagnostics are being emitted to a terminal, to a list box
UI, to a SARIF file, etc)

These sorts of things are why I only support a very simple
standardized interface, if anything. Trying to standardize something
with more bells and whistles will run into problems where not every
implementation can support it or will be willing to change their
diagnostic practices to support it.

~Aaron

On Mon, Oct 14, 2024 at 4:05 PM Barry Revzin via SG15
<sg15_at_[hidden]> wrote:
>
> Hey Tooling Study Group,
>
> I have this paper, P2758 (latest currently: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2758r3.html), which proposes low-level utilities for emitting messages during constant evaluation time.
>
> Those messages have three kinds (print, warning, and error) and can also be tagged. The intent of the tagging is to give the user the kind of control typically reserved for the compiler. That is, the format library can diagnose something with:
>
> std::constexpr_warning("format-too-many-args", "Format string consumed {} arguments but {} were provided.", current_arg, total);
>
> And that'll emit a compiler warning that maybe can be explicitly enabled (with some flag like -Wformat-too-many-args) or disabled (with some flag like -Wno-format-too-many-args). And possibly likewise with #pragmas for local blocks. Of course the actual mechanism is implementation-defined and it's likely the flags won't be exactly that so that they won't clash with actual implementation warnings.
>
> Evolution was happy with this proposal, but wanted you all to take a look at it for its use of tagging to make sure that this is a viable path. Right now, the paper's restriction on tagging is that it only contains, basically, a-z, A-Z, 0-9, an underscore, or a hyphen — although it presently also allows empty strings, which I'll change in a subsequent revision. That restriction avoids having to really deal with unicode stuff, while also matching the set of characters currently used in compiler flags anyway, so doesn't seem like it's cutting off anything useful to me.
>
> Thanks in advance for the feedback,
>
> Barry
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15