Proposal Question: Allow lambda conversion despite optional parameter or params differences

[jcouv]

As part of supporting default parameter values in lambdas (proposal, spec), we had decided to disallow the conversion from a lambda to a delegate type when there is a mismatch between default values or params modifiers.

For example:

delegate void D(int x, int y = 0, int[] z);
D d = (int a = 1, int b = 2, params int[] c) => { }; // conversion fails and error reported on all parameters

I'm proposing we revisit that decision to allow that conversion and merely warn on such lambda parameter differences.

Rationale

It seems more consistent to allow the conversion, just like we allow method group conversions with similar differences, because we know how to convert.

Also, there's a bit of a parallel with tuple conversions, where we merely warn for specifying different names in a tuple literal which are useless, but we allow the conversion from a tuple type and a tuple literal despite such name differences:

var t = (a: 1, b: 2);
(int x, int y) t2 = t;            // OK
(int x, int y) t3 = (a: 1, b: 2); // Warning on both elements

Note that he failure/absence of conversion can affect overload resolution:

void M(Delegate1 d1) { }
void M(Delegate2 d2) { }
M((int a = 1, int b = 2, params int[] c) => { }); // could bind to the first overload, the second overload, or both (ambiguity) depending on existence of conversion

[333fred]

Discussed in LDM on November 2nd: https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-11-02.md#default-parameter-values-in-lambdas

Conclusion

The existence of conversions from lambdas to delegate types will be unaffected by params or default parameter values. Differences in those will cause a warning later in the pipeline. Lambdas that do not have params/default parameter values will not warn when converted to delegate types with them. We will not warn for method group conversions that differ by params or default parameter values.