Type argument inference failing with unambiguous method group

[MorenoGentili]

C# 10 introduced natural types for lambdas and method groups. However, compilation error CS0411 still occurs when an unambiguous method group is passed as an argument to a generic method. Please consider this case, as discussed in #129

static bool IsEven(int x) => x % 2 == 0;

static void Test<T>(Func<T, bool> predicate)
{
}

// type inference succeeds here
var isEven = IsEven;

// But fails here, why?
Test(IsEven);

If the var assignment works, then the method invocation should as well.

Originally posted by @MorenoGentili in #129 (reply in thread)

[RikkiGibson]

Changing Test(IsEven) to Test(isEven) makes the error disappear. SharpLab. This makes me suspect that this is a compiler bug. It might be best to file an issue in roslyn.

Part of the problem might be that this was actually implemented as a "special" conversion which occurs when there's no target type or the target type is object or System.Delegate. But it still seems like the result type of this "conversion" should be able to contribute to type inference. cc @cston.

[333fred]

I doubt this was unintentional. @cston, was this one of the backcompat things we did?

[cston]

The local isEven has a delegate_type, and type inference for Test(isEven) will infer from the type arguments of the local type Func<int, bool> to the type parameters of the target type Func<T, bool>: see spec.

However, the method group IsEven has a function_type rather than a delegate_type, and there is no type inference rule for inferring from the parameter types of a function_type to the type parameters of the target type.

(By contrast, type inference of the corresponding lambda expression Test((int x) => x % 2 == 0); succeeds not because of function_type of the lambda but because type inference has a specific rule for anonymous functions: see spec.)

[MorenoGentili]

Thanks @cston for your detailed explanation.

because type inference has a specific rule for anonymous function

Would you consider adding a specific rule for method groups as well?

[jnm2]

(Which is what #129 has been asking for)

[RikkiGibson]

It wasn't clear to me if there was a specific reason this scenario wasn't supported as part of the lambda improvements in C# 10. For example, is there a compat concern or technical hurdle that makes it impractical?