csharpstandard icon indicating copy to clipboard operation
csharpstandard copied to clipboard

Grammar ambiguities

Open logeshkumars0604 opened this issue 1 year ago • 1 comments

Type of issue

Other (describe below)

Description

In the Grammar ambiguities section mentioned below,

If a sequence of tokens can be parsed (in context) as a simple_name, member_access, or pointer_member_access ending with a type_argument_list, the token immediately following the closing > token is examined, to see if it is:

... One of the relational operators < > <= >= is as; ...

If the following token is among this list, or an identifier in such a context, then the type_argument_list is retained as part of the simple_name, member_access or pointer_member-access and any other possible parse of the sequence of tokens is discarded. Otherwise, the type_argument_list is not considered to be part of the simple_name, member_access or pointer_member_access, even if there is no other possible parse of the sequence of tokens.

The statements

F(G<A, B>7);
F(G<A, B>>7);

will each be interpreted as a call to F with two arguments.

it is mentioned that if the token following the > token in a simple name / member access / pointer member access is one of the relational operators (< > <= >= is as), the simple name / member access / pointer member access will be interpreted with type argument list.

But in the mentioned example, F(G<A, B>>7), the token > is followed by the token >. Need help to understand why it is not being interpreted with type argument list.

Page URL

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/lexical-structure

Content source URL

https://github.com/dotnet/csharpstandard/blob/draft-v8/standard/lexical-structure.md

logeshkumars0604 avatar May 22 '24 06:05 logeshkumars0604

@logeshkumars0604 – Thanks for spotting this. The token > should not be in that list and needs to be removed. If you wish to submit a PR that removes it please do so, you can put me down as a reviewer.

Note there is a more complex disambiguation rule possible where > might be used, it is likely this error stems from that – but as the rest of that rule is not mentioned simply removing the errant > is a valid fix until, and if, that more complex rule is added to the Standard.

Nigel-Ecma avatar May 25 '24 22:05 Nigel-Ecma