Implement ref-kind modifiers on implicitly typed lambda parameters.

[keith-anders]

Championed issue: #338

I understand this will have to wait until the implementation for C# 10's lambda improvements are in. It seems possible that it will automatically "just work" at that time, if I read the Syntax proposal correctly, but I think it'll be worth at least testing for. If it doesn't work automatically after implementing the lambda improvements I'll be happy to pick this up and implement it at the time.

Test Ideas

• Language Version
• Parenthesized parameter list with each modifier (ref x) => ++x;
• Unparenthesized single parameter, both static and non-static: static out x => x = 42;
• When the ref-kind parameter's type is generic.
• Out parameters are required to be assigned, or else CS0177 is raised.
• In parameters must not be assigned, or else CS8331 is raised.
• The version with the implicit parameter type should emit the same IL as the version with the explicit parameter type.
• The lambda parameters must still have the ref-kind keyword or else CS1676 is raised.

I feel like the syntax could be very close between this and a left deconstruction, but I couldn't come up with a line of code that was sufficiently ambiguous to be a good test case. Suggestions?

Minor note: This is my first time raising an issue of substance on roslyn, so I am grateful for corrective feedback.

[cston]

Thanks @keith-anders.

I understand this will have to wait until the implementation for C# 10's lambda improvements are in. It seems possible that it will automatically "just work" at that time, if I read the Syntax proposal correctly

Currently the syntax in the proposal continues to require an explicit type if a modifier is provided. The question has been raised about whether to relax that requirement and allow ref-kind modifiers with implicitly typed parameters, but at this moment that is not included in the proposal.

[jaredpar]

Thanks for the interest and enthusiasm here 😄

Generally we recommend that contributors start off with bug fixes before diving into feature work. Feature work is very involved process. Even the simplest of features require a significant amount of review, testing and integration up the stack.

It's not just enough for us to make the compiler work, we have to make sure the entire ecosystem around the feature works as well. For example that means making sure that IDE intellisense works, formatting, typing, etc ... In addition to being work for the feature author to contribute it's also resources we need to allocate to review, validate and help guide the author through the odd ball cases that pop up. This is true irrespective of whether the feature author is community or works on the compiler team.

This is why we generally push for first contributions to be bug fixes. It's a way to get familiar with the code base, the type of problems that you need to be thinking about when contributing, the type of tests to author, etc .... Once contributors are experienced in bugs then we recommend moving into feature work.