On Wed, 23 Oct 2024 at 14:31, Corentin <corentin.jabot_at_[hidden]> wrote:

> Heh, having a different perspective is useful sometimes!
> Aaron pointed out that every time these discussions come around we struggle to reach a community consensus as to what we would actually need to meet the needs of users.
> But, I'm fairly confident both Aaron and I would favor a simple interface that can be iterated upon as we gather usage experience, and that we both want to make sure not to compromise the output, as you put it.
> We are acutely aware of a growing need for constexpr-debugging capabilities (which would be fairly different than poking at template instantiations) and in fact we have been musing with the idea of hooking constexpr evaluation to an actual debugger protocol,
> that would be quite neat - print-debugging gets annoying fast. Long term project though :)
>
> (Note that I'm not completely opposed to print, but there is the potential for it being a mess and having ways to disable that or even not having it own by default is probably going to be necessary)

So, does it make you happier if we do something along the lines of

6 Effects: During constant evaluation, a diagnostic message is
<ins>requested to be</ins> issued <ins>by the implementation</ins>
including the text of msg. Otherwise, no effect. <ins>The actual
effects of the request and the format of diagnostics are
implementation-defined</ins>
Recommended practice: <ins>Implementations should provide a mechanism
to cause the diagnostic to be issued similarly to other
diagnostics.</ins> Implementations should include the text of tag.str,
if provided, in the diagnostic.
<ins>[Note: Implementations are able to suppress the diagnostic, or
send it to an output different from that of other diagnostics. --End
Note]

Drafting Note: The note is not giving a permission, it's explaining a
permission given by the normative effects and clarifying what the
recommended
practice, among other things, means.
Drafting Note 2: "Similarly" doesn't mean "identically".