Proposal: Expand method type inference to more use cases

[Corey-M]

Summary

Methods may not be the direct target of extensions or switch expressions, cannot be returned from expressions and so on. This should be changed to allow more direct usage of methods.

Description

In general a method cannot be the input or output of any expression except conversion (implicit or explicit) to a delegate type. We can assign (for simple example) Path.GetFileName(string path) to a Func<string, string> delegate, or we can cast it with (Func<string, string>). We can then consume that delegate in expressions, return it as the result of some expression, use it as the target of an extension and other things we cannot do directly with the method itself.

We can also use type inference on the method to assign it to a var, with the predictable result that the assigned variable will be of type Func<string, string>.

There are a variety of cases where extensions and expressions are useful with delegate types, but using those same extensions/expressions with methods is expressly forbidden. I propose that this be relaxed somewhat by using the same type inference as used for the implicitly typed delegate to implicitly convert the method inline.

Use Cases

Switch Expressions

Methods currently require casting to delegate explicitly or implicitly to be used as the results of a switch expression:

static int M1(string _) => 1;
static int M2(string _) => 2;

int i = 2;
string s = "test";

// 1. Successful
Func<string, int> f1= i switch { 1 => M1, 2 => M2, _ => throw new() };
f1(s);

// 2. Desired, fails with CS8506 - No best type was found for the switch expression
var f2 = i switch { 1 => M1, 2 => M2, _ => throw new() };
f2(s);

// 3. Successful, but wastes space
var fm1 = M1;
var fm2 = M2;
(i switch { 1 => fm1, 2 => fm2, _ => throw new() })(s);

// 4. Successful, but ugly
((Func<string, int>)(i switch { 1 => M1, 2 => M2, _ => throw new() }))(s);

// 5. Success, only slightly less ugly
(i switch { 1 => (Func<string, int>)M1, 2 => M2, _ => throw new() })(s);

// 6. Sort of desired, fails with CS0146 - Method name expected
(i switch { 1 => M1, 2 => M2, _ => throw new() })(s);

I propose that all usages like this be treated as though implicitly typed and converted. In this case the two failed samples would succeed as if they were explicitly cast. Sample 4-6 would ideally have identical output code.

Extensions

My primary interest for extension methods written for delegate types to work on methods directly without casting.

static int M1(string _) => throw new();
static int M2(string s) => s.Length;

const string s = "test";

// These fail, but should work:
int res1 = M1.Try(s, -1); // should be: -1
int res2 = M2.Try(s, -1); // should be: 4

// This is the way it works now:
int res1a = ((Func<string, int>)M1).Try(s, -1); // returns -1
int res2a = ((Func<string, int>)M2).Try(s, -1); // returns 4

static class Extensions
{
	// Example only, not real-world code
	public static T? Try<T1, T>(this Func<T1, T> func, T1 p1, T whenFailed)
	{
		try { return func(p1); }
		catch { }
		return whenFailed;
	}
}

In this example when attempting to use M1 or M2 in a member access expression (i.e. the . symbol is encountered) the method should be implicitly cast to the inferred delegate type Func<string, int> before continuing, using the same methodology as assigning to an implicitly typed local.

---

Notes

1. No changes are required to the runtime, this is purely syntactic.
2. This is not a breaking change as none of the use cases overlap existing valid syntax.
3. Applies to Method only, delegates don't need it and lambdas are already covered.
4. No complex resolution should be attempted, only what already works for type inference.
5. If it doesn't work for var assignment, it won't work here.
   • Specifically, overloaded methods cannot be supported as we don't have the parameters to disambiguate between them.
6. Type inference code should be shared between these cases and the implicitly typed local case.
7. This is distinct from Proposal: Extension Methods on Method Groups #5482 but would enable some subset of that proposal's functionality.

[timcassell]

Dupe of #9006