Access specifier grammar is not clear

[peterwvj]

As explained in overturetool/overture#610 there used to be a minor issue with parsing of access specifiers that has now been fixed. In addition, there is another problem with the way the grammar is defined.

In the LRM the access operation definition nonterminal defines two orderings of keywords. This made sense when it could only be either static or an access specifier, but with pure and async in the mix we have various possibilities, and picking two arbitrary orderings seems strange:

access operation definition = ( [ ‘pure’ ], [ ‘async’ ] [ access ], [ ‘static’ ]) |
( [ ‘pure’ ], [ ‘async’ ] [ ‘static’ ], [ access ]),
operation definition ;

access = ‘public’ | ‘private’ | ‘protected’ ;

[paulch42]

I think Nick's suggestion is

access operation definition =  {'pure'|'async'|access|'static'}, operation definition;

I propose we accept this and the constraint of no duplicates is external to the grammar.

[tomooda]

I agree. Nonsense combinations like "public private" can be handled as a semantic issue.

[peterwvj]

The LB support the change proposed, which is also compatible with the tools. The LRM still needs to be updated to reflect this change.

[tomooda]

done. overturetool/documentation@1985b15

[peterwvj]

Thanks!