On Wed, Oct 23, 2024 at 3:14 AM Aaron Ballman via SG15 <
sg15_at_[hidden]> wrote:

> On Tue, Oct 22, 2024 at 1:46 PM Barry Revzin <barry.revzin_at_[hidden]>
> wrote:
> >
> >
> >
> > On Wed, Oct 16, 2024 at 8:40 AM Aaron Ballman <aaron_at_[hidden]>
> wrote:
> >>
> >> On Wed, Oct 16, 2024 at 6:10 AM Jonathan Wakely <cxx_at_[hidden]> wrote:
> >> >
> >> >
> >> >
> >> > On Tue, 15 Oct 2024 at 18:53, Aaron Ballman via SG15 <
> sg15_at_[hidden]> wrote:
> >> >>
> >> >> 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)
> >> >
> >> >
> >> > We already have a distinction between #error and #warning, how is
> this any different?
> >> > constexpr_print just outputs a message at compile time (which you've
> said is fine).
> >>
> >> Because it adds another layer of distinction (constexpr_print_str)
> >> which may or may not make sense to any given implementation. In Clang
> >> specifically, is that a note or a remark? (There are problems with
> >> whichever one we pick, so it'd probably be an entirely new thing, but
> >> none of our users have actually asked for something like that, at
> >> least that I'm aware of.)
> >
> >
> > I've been thinking of how you expect me to respond to this, and I'm
> still not entirely sure. You're not aware of ANY of your users having asked
> for something like this? Not even the user who is asking for something like
> this so hard that he wrote a paper, took it through several groups, and got
> strong (nearly unanimous) consensus for its adoption?
>
> There are no feature requests for such a thing on Clang's issue
> tracker, nor was there a question or RFC on our Discourse forums, and
> no PRs were opened trying to implement the feature, and I couldn't
> find any blog posts about such a feature for, etc. So yes, I'm not
> aware of any users asking for something like constexpr_print despite
> there being several instances where users have asked for things like
> directly emitting errors or warnings.
>

FYI, I pretty much agree with all the points that Jonathan made.
As long as there is no requirement put on the implementation on how the
warnings are produced and controlled, I have personally no concern with
this feature in Clang.
I think the tag is useful, as long as we can decide to use it however we
want - if we decide to do something with it (and we certainly don't want to
affect existing diagnostic groups and flags - user creativity should be
contained)
I certainly agree that "print" is less useful than warning and error (We
basically never have non-error non-warning diagnostics - very much
purposefully ) - maybe getting rid of print in the first iteration of this
paper would help increase consensus.
I think a tag on error sort of makes sense. People will want to control and
disable egregious uses of user generated diagnostics.

Beyond that, I think what the paper proposes makes sense - it is a fairly
minimal proposal, as it should be.
Any more granularity over the diagnostics engine should either remain in
the realm of compiler extensions, or require a lot more usage experience.

And we sort of need this feature to have any chance of making reflection
remotely maintainable.



>
> ~Aaron
>
> >
> > Barry
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>