On Sat, Nov 12, 2022 at 11:45 AM Ville Voutilainen
<ville.voutilainen_at_[hidden]> wrote:
>
> On Sat, 12 Nov 2022 at 18:37, Aaron Ballman <aaron_at_[hidden]> wrote:
>
> Thanks for reporting this!
>
> One snag:
>
> > Further, we are not convinced the effects of this paper are in the
> > best interests of users. The result of voting in favor of this
> > proposal is for this code to be diagnosed in C++11 mode:
> >
> > [[deprecated("this has a reason")]] int foo;
> > [[nodiscard("this also has a reason")]] int func();
> >
> > because this proposes, as a DR, to require an implementation to
> > diagnose the syntactic violation of providing an attribute argument
> > list when the grammar does not allow one for these attributes in that
> > language mode.
>
> Uhh.. when the grammar doesn't allow an argument list for an
> attribute, I find it
> quite redundant for the spec to separately say that that's ill-formed. o_O
> I don't think this clarification causes your concerns, although it may clarify
> misunderstandings and may nullify previous expectations but.. in what
> world are grammar violations expected not to be diagnosed?
>
> In other words, I think the problem was caused much earlier, by making the
> specific attributes' specifications the way they are. I don't think
> this clarification
> has an actual normative effect.

Okay, that's a fair point -- this resolution doesn't make that
situation any worse, thank you for correcting that!

> Having said all that, I do agree with the rest of your take, and I
> agree that this
> is a problem for C compatibility, and that this is a significant
> burden for implementations,
> and that this is not all that helpful to users either. My position
> remains that this should
> be more a QoI matter than a grammatic rule. That wouldn't change the
> current situation,
> implementations that do diagnose attributes can continue to do so, and we'd make
> the various existing approaches conforming too. Fixing the current
> situation imposes
> work on implementation vendors, work the energy of which could be used
> far better
> elsewhere.

+1, I'm far more comfortable with leaving this to QoI.

~Aaron