simple-declaration:
decl-specifier-seq init-declarator-listopt ;
attribute-specifier-seq decl-specifier-seq init-declarator-list ;
attribute-specifier-seqopt decl-specifier-seq ref-qualifieropt [ identifier-list ] initializer ;
but perhaps this could be changed to:
simple-declaration:
decl-specifier-seq init-declarator-listopt ;
attribute-specifier-or-decl-specifier-seq init-declarator-list ;
attribute-specifier-or-decl-specifier-seq ref-qualifieropt [ identifier-list ] initializer ;
attribute-specifier-or-decl-specifier-seq:
attribute-specifier-or-decl-specifier-seq attribute-specifier-or-decl-specifier
attribute-specifier-or-decl-specifier
attribute-specifier-or-decl-specifier:
attribute-specifier
decl-specifier
which might not impose a huge burden on compiler writers.
Thanks,
On Jan 18, 2023, at 12:35 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
On Wed, Jan 18, 2023 at 11:51 AM Robert Allan Schwartz via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Header <stop_token>:
[[nodiscard]] friend bool operator==(const stop_token& lhs, const stop_token& rhs) noexcept;
I would have thought that this should be:
friend [[nodiscard]] bool operator==(const stop_token& lhs, const stop_token& rhs) noexcept;
i.e. the attribute pertains to the function, not to the friend declaration,
but I was told that an attribute cannot appear in this position,
hence it must be as it is in <stop_token>.Perhaps the grammar should be amended to allow an attribute in this position?
Hi Robert,(Unlike your other thread, this one is a feature request / behavioral change, and thus would have to be proposed as a paper and discussed in committee; even if you had wording for it, it should never be submitted as a pull request. Just so we're clear on that. :))
This proposal lacks motivation. You're asking to complicate the grammar, right? This will create burdens for the committee/specifiers, for compiler vendors/implementors, for users who now have to deal with yet another little difference between C++2b and C++2c. Those are all costs. And the benefit is... what? That you now get a stylistic choice of two different places it's legal to put attributes like `[[nodiscard]]`?Alternatively, just don't do any of that; and then the only cost is to (an ever-decreasing number of) programmers who would stylistically prefer to write `friend [[nodiscard]] bool` but are forced by the simple grammar of C++ to write `[[nodiscard]] friend bool`. That's a much smaller cost than all the costs above; and it has all the same benefits plus two — compiler enforcement of the preferred style (the alternative style is rejected by the compiler, hooray!), and its already-being-implemented-as-the-status-quo (so vendors don't need to do any work).
my $.02,–Arthur