Feature / Architecture Discussion: Optional and Named arguments

[siegfriedpammer]

Language Feature(s):

• C# 4.0 optional arguments
• C# 4.0 named arguments
• C# 7.2 non-trailing named arguments

These features should be implemented in one go, because they depend on each other.

Affected areas:

• ILAst
• ILInlining
• CallBuilder

1) Optional Arguments:

Optional values can only be: ldnull, ldstr, ldc.*, default.value

1. CallBuilder: Remove optional arguments, if overload resolution allows it.

2) Named Arguments:

CallInstruction currently does not distinguish between the argument evaluation order, and the parameter order. The CallInstruction.Arguments collection must be in evaluation order. But we can extend CallInstruction to allow more flexible mapping of arguments to parameters.

1. Extend CallInstruction: Add int[] argumentToParameterMap. For each argument index, this would specify the corresponding parameter index in the method's parameter collection.
   • The this parameter (which isn't present in the method's parameter collection) could be represented as -1. It must remain argument 0.
   • CallInstruction.CheckInvariant should check that the mapping between arguments and parameters is 1-to-1.
   • All code that deals with call arguments+parameters will need adjustment!
2. Add some ILAst transform that reorders both the call arguments and adjusts the argumentToParameterMap in order to open up new inlining possibilities (maybe as extension to ILInlining? or as a new StatementTransform?)
3. CallBuilder: use named arguments when argument order differs from parameter order
   • When using named arguments, emit NamedArgumentExpression
   • Also report the argument names to the resolver.

3) Non-trailing Named Arguments:

• Do they change/affect overload resolution rules in any way? (see https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.2/non-trailing-named-arguments.md)
  • Yes: only overloads with matching parameter names are applicable, so adding names can resolve ambiguities.
  • But I don't think adding names can change the result of an already-successful overload resolution.

1. CallBuilder: Add NamedArgumentExpression for any constants

Related:

• Support for nameof in well-known cases (Exception ctors, CallerMemberNameAttribute)
• CallerMemberNameAttribute: Remove ldstr arguments if optional and value == CurrentMember.Name

[dgrunwald]

"2) Named Arguments" is now implemented.
3) would be easy to do now.

1. will first require some refactoring of the CallBuilder...

[siegfriedpammer]

Optional arguments are implemented as of 4776331