Proposed change to method group natural type

[jcouv]

Determine natural type of method group by looking scope-by-scope

Speclet: #7399

For reference:

https://github.com/dotnet/csharplang/blob/main/proposals/csharp-10.0/lambda-improvements.md#natural-function-type

A method group has a natural type if all candidate methods in the method group have a common signature. (If the method group may include extension methods, the candidates include the containing type and all extension method scopes.)

The current behavior leads to an arguably unnecessary error in the following scenario, where an irrelevant extension method (which we have no chance of binding to) causes an error on z.

System.Action x = c.M;         // C.M()
System.Action<object> y = c.M; // E.M(C, object)
var z = new C().M;            // the delegate type could not be inferred

public class C
{
  public void M() { }
}

public static class E
{
  public static void M(this C c, object o) { }
}

When the irrelevant extension method has the right signature, we can infer the type of the delegate, but we'll still bind to the instance method (ie. it wins over the extension method).

var z = new C().M;            // C.M()

public class C
{
  public void M() { }
}

public static class E
{
  public static void M(this C c) { }
}

I would propose that we align the logic that infers the delegate type with the logic that ends up picking which method to bind to.

I would propose the following rule:

Considering each scope in turn: instance methods, then each scope of extension methods
If we have a single signature in that scope, then we can infer the function type.

Note that we'll keep the following existing behavior, where we can infer the delegate type but cannot select which method to bind to:

var z = new C().M;            // ambiguous, but we could infer the delegate type

public class C
{
}

public static class E1
{
  public static void M(this C c) { }
}
public static class E2
{
  public static void M(this C c) { }
}

One advantage of the current design is that it reduces surprises for users who change code from an explicit type to a var:
If you start with System.Action a = c.M;, the method will have been picked by overload resolution. But when you switch to var a = c.M; the type is determined in a different way which can be jarring. So requiring all signatures to match reduces the surprise on the type. But it does not mitigate the surprise on which method we actually bind to...

Relates to test plan dotnet/roslyn#52192 (lambda improvements) and dotnet/roslyn#66722 (extension types)

Design meetings

• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-07-24.md#method-group-natural-types-with-extension-members
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-10-16.md#determine-natural-type-of-method-group-by-looking-scope-by-scope

[FaustVX]

Does this allows us to write :

Console.WriteLine.M();

static class Ext
{
  public static void M(this Action<string> action) { … }
}

[jcouv]

Does this allows us to write :

Console.WriteLine.M();

No. That scenario will not be affected (remains disallowed).

[FaustVX]

@jcouv

Does this allows us to write :

Console.WriteLine.M();

No. That scenario will not be affected (remains disallowed).

Is this something that may be implemented in the future ?

[CyrusNajmabadi]

Yup. It's something we're actively looking into

[FaustVX]

Yup. It's something we're actively looking into

Nice. Thanks.

[alrz]

A method group has a natural type if all candidate methods in the method group have a common signature

If I understand this correctly, perhaps it would allow #129?

[jcouv]

If I understand this correctly, perhaps it would allow #129?

The proposal in OP relates to which methods are considered to determine the natural type, but does not other affect how the methods are processed. Any scenario involving a single method (such as the IsEven example linked) behaves the same in the current implementation/spec and this proposed modification. So the linked scenario would remain disallowed (it's a separate problem).

[jcouv]

The proposal was discussed and approved in LDM 2023-07-24

[jcouv]

Closing as duplicate of #7429 which is already in the working set and has a speclet document draft.