Type argument inference with unambiguous method group

[jnm2]

@jnm2 commented on Mon Jan 30 2017

Please allow the following. I see no possible ambiguity in this scenario. The IsEven and Test method groups have only one overload which fits the delegate signature.

class Program
{
    public static void Main()
    {
        Test(IsEven);
    }

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

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

Expected Behavior:
Infers Test<int>(IsEven) and compiles

Actual Behavior:
CS0411 The type arguments for method 'Program.Test(Func<T, bool>)' cannot be inferred from the usage. Try specifying the type arguments explicitly.

---

@jaredpar commented on Mon Jan 30 2017

Believe this is by design but will let @gafter comment on exactly how.

---

@gafter commented on Mon Jan 30 2017

Type inference doesn't infer based on an argument that is a method group, no matter how many or few members the method group has. The conversion from a method group to a delegate (of some particular type) occurs after type inference has completed to determine what that delegate type is.

Having said that, I imagine it might be possible to modify (the specification for) type inference to get the behavior @jnm2 would like. Who would like to take a crack at it?

[bbarry]

Is this something that should be related to Bestest Betterness #98?

[gafter]

@bbarry

Is this something that should be related to Bestest Betterness #98?

It depends on the shape of the proposed solution/specification. Absent a proposed solution, I would say no.

[DavidArno]

This is such an annoying feature of C#. Having it infer the type parameters when the method group only consists of one method would be a really useful addition to the language.

[louthy]

This does seem like a major flaw that needs to be rectified, especially for those of us using first-class functions everywhere -- it's a real pain point. The fact that this invisible thing called a 'method group' (which no coder understands unless they know how the compiler works) gets in the way of treating methods as first-class functions is crazy. Even if there are multiple methods in the group.

"Method group" shouldn't even be in a C# programmer's lexicon.

[bradphelan]

I just got bitten by this. Thought I was being really clever and created a t4 template to generate helpers for partial function application only to find I couldn't pass "method groups" to them.

https://gist.github.com/bradphelan/ca92cd8e8a7b619712799474a27f60e6

[gafter]

I hear people asking for a solution to this. Has anyone a proposed solution (i.e. a modification to the language specification) that is implementable?

[DavidArno]

@gafter,

How about the following as a starting point:

1. Change:

Explicit parameter type inferences

An explicit parameter type inference is made from an expression E to a type T in the following way:

If E is an explicitly typed anonymous function with parameter types U1...Uk and T is a delegate type or expression tree type with parameter types V1...Vk then for each Ui an exact inference (Exact inferences) is made from Ui to the corresponding Vi.

To:

Explicit parameter type inferences

An explicit parameter type inference is made from an expression E to a type T in the following way:

If E is an explicitly typed anonymous function, or a method group with exactly one method, with parameter types U1...Uk and T is a delegate type or expression tree type with parameter types V1...Vk then for each Ui an exact inference (Exact inferences) is made from Ui to the corresponding Vi.

2. Change:

The first phase

For each of the method arguments Ei:

• If Ei is an anonymous function, an explicit parameter type inference (Explicit parameter type inferences) is made from Ei to Ti

To:

The first phase

For each of the method arguments Ei:

• If Ei is an anonymous function, or a method group with exactly one method, an explicit parameter type inference (Explicit parameter type inferences) is made from Ei to Ti

(my additions in italics).

This seems trivially simple. So what have I missed? 😁

[gafter]

That doesn't quite work. The type of a method in a method group isn't known until after type inference (because it could be a generic method).

[gafter]

Also, the number of methods in a method group isn't a defined concept. When there is no instance method but there is an extension method, what is the number of methods in the method group?

[gafter]

Also, when there is exactly one method in the method group but with a params parameter, it could still be used in two different ways (normal form and expanded form), each of which could result in a different type inference result.

[jnm2]

This keeps coming back. What's the smallest change we can make to the spec that would allow this to resolve?

[alrz]

I think the root of the problem is where for type inference on the method group, we need to know what the exact delegate type it is going to.

We could infer T just like how we infer a type for default or new(): assume the parameter type T on the delegate type is compatible with any parameter type yielded from the method group overload resolution - so its type (which we don't know yet) does not contribute to it. later, if the overload resolution succeeds, then we give T the the same corresponding parameter type from the winner candidate

[alrz]

As a proof of concept, here's the minimum changes for such program to successfully compile:
alrz/roslyn@c96534d Note: the implementation is kind of wasteful because we resolve the method group twice (once in each phase) which I think shouldn't be necessary.

[LarsKemmann]

Would this help with this issue? If so, then this would be a really helpful improvement!

[alrz]

I recently hit something similar to this but I'm not sure that would be the same issue as it won't work with a lambda expression either,

interface I {
    Task<object> MethodAsync(object x);
}

static class C {
    static void Test()
    {
        Create((I v) => v.MethodAsync); // error
        Create((I v) => x => v.MethodAsync(x)); // error

        Create<object, object, I>(v => v.MethodAsync); // ok
    }

    static Func<T, U> Create<T, U, V>(Func<V, Func<T, Task<U>>> factory) => null;
}

[PhilipAtz]

Is this change happening? There seems to be agreement that it would be a good thing to have.

[YairHalberstadt]

This isn't championed so isn't on the roadmap for now.

That said, if you (or anyone else) wants to push this forward, opening an issue containing a formal proposal explaining exactly how the c# spec should change could definitely increase the likelihood of this happening.

[alrz]

This is likely addressed by "lambda natural type" feature (@cston?)

[MorenoGentili]

This is likely addressed by "lambda natural type" feature

That's what I thought, too. C#10 is still not inferring the type though.
Funny things is, this does work.

var isEven = IsEven;
Test(isEven);

[adam-dot-cohen]

That's because you're converting it to Func<int, bool> which is the equivalent of...

public static Func<int, bool> IsEven = (int x) => x % 2 == 0;

Did this ever get resolved?

[jcouv]

I drafted a spec change to solve this, along with various method group improvements.

Here's the relevant part:

We modify the explicit parameter type inference rules to not just apply to explicitly-typed lambdas, but also to method groups:

An explicit parameter type inference is made from an expression E to a type T in the following way:

• If E is an explicitly typed anonymous function *or method group with a unique signature with parameter types U₁...Uᵥ and T is a delegate type or expression tree type with parameter types V₁...Vᵥ then for each Uᵢ an exact inference is made from Uᵢ to the corresponding Vᵢ.

That is the mechanism that allowed explicitly-typed lambdas to contribute to type inference:

Test((int i) => true); // infers Test<int>
void Test<T>(Func<T, bool> predicate) { }

So this change should allow a method group with a unique signature to work:

Test(IsEven); // would now also infer Test<int>
void Test<T>(Func<T, bool> predicate) { }

[alrz]

Would this affect type inference of type parameters on the method group itself? Sounds like there's something special about return-type that cause it to not being inferred where possible. (sharplab.io)

using System;	

TestNone(Both<int, bool>);  // (1)
TestNone(In);               // ok
TestNone(Out<bool>);        // (2)
TestNone(None);             // ok

//TestIn(Both);
//TestIn(In);   
TestIn<int>(Out<bool>);     // (3)
TestIn<int>(None);          // proposed

//TestOut(Both);
TestOut(In);                // ok
//TestOut(Out); 
TestOut(None);              // ok

//TestBoth(Both);
//TestBoth(In); 
//TestBoth(Out);
TestBoth<int, bool>(None);  // (4)


static R    Both<T, R>(T arg) => throw null!;
static bool In<T>     (T arg) => throw null!;
static T    Out<T>    (int arg) => throw null!;	 
static bool None      (int arg) => throw null!;	


static void TestNone      (Func<int, bool> predicate) { }
static void TestIn<T>     (Func<T, bool> predicate) { }
static void TestOut<T>    (Func<int, T> predicate) { }
static void TestBoth<T, R>(Func<T, R> predicate) { }

[jcouv]

@alrz No, I don't think it would not affect the determination of the method group itself.

I didn't understand the numbered comments "(n)" and the "proposed" line in the code sample. (TestIn<int>(None); works already)
I expect TestBoth(None) and TestIn(None) to start working with this proposal. (Testout(None) works already, I believe because we already have a special rule for inference of return types)

I need to look more at the interaction between conversion rules and inference rules. For example, could TestIn(Out) work? (I believe it would still not work with this proposal)

[alrz]

"proposed" is the example in OP, type args for the rest should be possible to infer when unspecified.

Not sure if/how lambda return-types contribute to type inference, but if that's the case I guess that's also applicable to method groups.

[ceztko]

Will the proposal be delivered for .NET9?

[jcouv]

Unlikely for .NET 9. We're heads down to deliver the features we're already working on (see feature status) already.