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.

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.