Parser depends on code order of attributes

[robhol]

Describe the bug According to the Parser docs, behavior depends on the order in which the attributes appear in code. Unfortunately, .NET does not actually have a concept of an ordering for attributes, or of "code order" in general. In other words:

[A][B] T someMember;
[B][A] T someMember;
[A, B] T someMember;
[B, A] T someMember;

are all equivalent according to the specification. This means there are no guarantees the order will be as intended and this behavior could break unpredictably for several reasons, tied to implementation details in the compiler and BCL.

Which libraries does it affect? Parsing

To Reproduce n/a

Expected behavior When attributes or members need an explicit ordering, it is typically provided explicitly. One possibility would be e.g.

[Right(3, "^")]
[Left(2, "*", "/", "%")]
[Left(1, "+", "-")]

Environment (please complete the following information): n/a

Additional context C# spec on attribute specifications

[LPeter1997]

Good catch, thanks for the report. Indeed, this means that explicit ordering should be introduced.

[robhol]

It just occurred to me I have probably been completely in the wrong about this. Being reliant on sourcegen means the order is well defined, the limitation I mentioned applies to "traditional" compilation and Reflection.

My apologies!