On Fri, Jan 20, 2023 at 12:23 AM Robert Allan Schwartz <
notbob_at_[hidden]> wrote:

>
>
> On Jan 18, 2023, at 9:04 PM, Andrew Tomazos <andrewtomazos_at_[hidden]>
> wrote:
>
> You can see the grammar here:
>
> https://eel.is/c++draft/gram
>
> The relevant productions are attribute-specifier-seq (which [[nodiscard]]
> matches) and decl-specifier (which friend matches).
>
> For each attribute-specifier-seq there is also corresponding prose that
> states what entity the attributes pertain to.
>
> So your proposal would need to specify what changes to the grammar you
> propose
>
>
> Here are the rules in the grammar that currently (i.e. in the 2020
> Standard) require attribute specifiers to come before decl specifiers:
>
> 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.
>
> and you would have to test that those changes don't create any new
> ambiguities (or if they do, you need to add a disambiguation rule which
> states which branch of the grammar is taken in the case of an ambiguity.
> Search for "resolved in favor of" for examples.)
>
>
> How would I perform that test?
>

I'm not actually sure. I generally stare at the grammar and try to imagine
what kind of ambiguities that could come up as a kind of thought
experiment. I remember something about being taught that there is no
algorithm for this sort of thing for some reason, but I'm not sure whether
or not that result applies here.




> Thanks,
>
> Robert
>
>
>
>
>
> On Thu, Jan 19, 2023 at 3:51 AM Robert Allan Schwartz via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Hello,
>>
>> Today I am making my first posts to this group. Please forgive me if I
>> make mistakes. Thank you.
>>
>> Here is the context:
>>
>> 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?
>>
>> What do you think?
>>
>> Thank you,
>> Robert Schwartz
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>
>