C++ Logo


Advanced search

Re: [wg14/wg21 liaison] [cpp] Implementer concerns with Defect Report issue 2538 (Can standard attributes be syntactically ignored?) in P2710R0

From: Aaron Ballman <aaron_at_[hidden]>
Date: Sat, 12 Nov 2022 11:54:21 -0500
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.


Received on 2022-11-12 16:54:34