Grammar rule *parameter_modifier* disallows valid V7 constructs

[RexJaeschke]

[I stumbled on this today while looking at how to spec the addition of scoped to a parameter for a future version.]

The relevant grammar for method parameters in §15.6.2.1 is, as follows:

fixed_parameter
    : attributes? parameter_modifier? type identifier default_argument?
    ;

parameter_modifier
    : parameter_mode_modifier
    | 'this'
    ;

parameter_mode_modifier
    : 'ref'
    | 'out'
    | 'in'
    ;

Rule parameter_modifier allows parameter_mode_modifier or this, but not both. However, two combinations of these are permitted, as follows:

public static class E
{
    public static void F1b(this in int p) { }
    public static void F1d(this ref int p) { }
}

This possibility is supported by the text in §15.6.10 Extension methods, which states:

When the first parameter of a method includes the this modifier, that method is said to be an extension method. Extension methods shall only be declared in non-generic, non-nested static classes. The first parameter of an extension method is restricted, as follows:

• It may only be an input parameter if it has a value type
• It may only be a reference parameter if it has a value type or has a generic type constrained to struct
• It shall not be a pointer type.

I propose the following grammar change:

parameter_modifier
    : parameter_mode_modifier
    | 'this' parameter_mode_modifier?
    ;

Now this new grammar also allows this out, which according to my compiler is not permitted [CS8328], and that suggests we also add to the extension bullet list above, the following constraint:

• It shall not be an output parameter.

[RexJaeschke]

Re my second suggestion, I just found the following in §15.6.2.1:

If the parameter is a struct type or a type parameter constrained to a struct, the this modifier may be combined with either the ref or in modifier, but not the out modifier. Extension methods are further described in §15.6.10.

That said, having the new bullet I proposed clarifies it at the parameter end of the call in the case of extension methods, which are not singled out by the above quote.

[Nigel-Ecma]

The ordering is flexible:

Suggested change

	| 'this' parameter_mode_modifier?
	| 'this' parameter_mode_modifier?
	| parameter_mode_modifier? 'this'

[RexJaeschke]

My test shows that the order is indeed flexible. Given Nigel's proposal, this on its own would be ambiguous, but I think ANTLR chooses the lexical-first rule that matches, right, Nigel?

[Nigel-Ecma]

@RexJaeschke – Yes, ANTLR resolves such ambiguity by picking the first alternative. We have noted elsewhere where the grammar relies on this, however in this case as the two alternatives represent exactly the same thing I don’t think a note is necessary.

[KalleOlaviNiemitalo]

It was not originally so flexible, see https://github.com/dotnet/csharplang/blob/8bd52cca31b40d9720a98629aae9a0cd89bb92ec/meetings/2017/LDM-2017-12-04.md. But I'm not sure which version of C# got that change.

[KalleOlaviNiemitalo]

The Roslyn change was dotnet/roslyn#23643. According to dotnet/csharplang#1022, this change is in C# 7.3. So OK for the ECMA C# 7 spec.

[Nigel-Ecma]

Requires a change to the grammar, apart from that the changes are good.

In the preexisting text I did notice that a reference parameter can be of a generic type constrained to a struct, an input parameter cannot be, and there appears to be no explanation why. The answer can be found in the Readonly references proposal, should something (normative or informative) be added?

[jskeet]

Can we rename parameter_modifier to parameter_modifiers? It doesn't feel like this ref is a single parameter modifier. This is purely a stylistic thing, and I'm happy to be overruled.

[Nigel-Ecma]

Can we rename parameter_modifier to parameter_modifiers? It doesn't feel like this ref is a single parameter modifier. This is purely a stylistic thing, and I'm happy to be overruled.

I'll vote against on this one – not because I think the current naming in this area is good, it isn’t really, but because making it plural won’t make it any better so stick with the status quo.

[jskeet]

(Like Nigel, I'm basically happy with this, but I agree with the ordering flexibility.)

[jskeet]

While we're here, is it worth being consistent within this bullet list as to whether we end with a period or not?

[BillWagner]

Also, basically happy as well.

[jskeet]

Note for the February meeting: this PR has not changed (as far as I can see) since November.

[jskeet]

(Closure was accidental.)