73

Given this code:

class C
{
    C()
    {
        Test<string>(A); // fine
        Test((string a) => {}); // fine
        Test((Action<string>)A); // fine

        Test(A); // type arguments cannot be inferred from usage!
    }

    static void Test<T>(Action<T> a) { }

    void A(string _) { }
}

The compiler complains that Test(A) can't figure out T to be string.

This seems like a pretty easy case to me, and I swear I've relied far more complicated inference in other generic utility and extension functions I've written. What am I missing here?

Update 1: This is in the C# 4.0 compiler. I discovered the issue in VS2010 and the above sample is from a simplest-case repro I made in LINQPad 4.

Update 2: Added some more examples to the list of what works.

scobi
  • 14,252
  • 13
  • 80
  • 114

5 Answers5

40
Test(A);

This fails because the only applicable method (Test<T>(Action<T>)) requires type inference, and the type inference algorithm requires that each each argument be of some type or be an anonymous function. (This fact is inferred from the specification of the type inference algorithm (§7.5.2)) The method group A is not of any type (even though it is convertable to an appropriate delegate type), and it is not an anonymous function.

Test<string>(A);

This succeeds, the difference being that type inference is not necessary to bind Test, and method group A is convertable to the required delegate parameter type void Action<string>(string).

Test((string a) => {});

This succeeds, the difference being that the type inference algorithm makes provision for anonymous functions in the first phase (§7.5.2.1). The parameter and return types of the anonymous function are known, so an explicit parameter type inference can be made, and a correspondense is thereby made between the types in the anonymous function (void ?(string)) and the type parameter in the delegate type of the Test method’s parameter (void Action<T>(T)). No algorithm is specified for method groups that would correspond to this algorithm for anonymous functions.

Test((Action<string>)A);

This succeeds, the difference being that the untyped method group parameter A is cast to a type, thereby allowing the type inference of Test to proceed normally with an expression of a particular type as the only argument to the method.

I can think of no reason in theory why overload resolution could not be attempted on the method group A. Then—if a single best binding is found—the method group could be given the same treatment as an anonymous function. This is especially true in cases like this where the method group contains exactly one candidate and it has no type parameters. But the reason it does not work in C#4 appears to be the fact that this feature was not designed and implemented. Given the complexity of this feature, the narowness of its application, and the existance of three easy work-arounds, I am not going to be holding my breath for it!

Jeffrey L Whitledge
  • 58,241
  • 9
  • 71
  • 99
  • 2
    Thank you for such a thoroughly explained walk through all of the cases. This settles the question for me! – scobi Jun 03 '11 at 22:34
  • 4
    Overload resolution cannot be attempted because overload resolution determines a *method* given a *method group* and *arguments*. But it is the argument types we are attempting to work out! That's a chicken-and-egg problem which we do not attempt to solve. – Eric Lippert Jun 07 '11 at 14:57
  • 8
    Saying that "the method group contains only one method so let's provisionally say that overload resolution succeeds even if we don't know the arguments" is essentially adding a new, weird overload resolution algorithm that only succeeds in the rare case of the method group containing one method. We really don't want to go there; do you really want a situation where adding a second overload severely changes how type inference works? – Eric Lippert Jun 07 '11 at 14:58
  • 5
    Finally, note that in C# 4, if the thing you are attempting to infer is a *return type* and all the *argument types* have already been inferred successfully then overload resolution will proceed. – Eric Lippert Jun 07 '11 at 14:59
  • @EricLippert "a new, weird overload resolution algorithm that only succeeds in the rare case of the method group containing one method?" If that allows me to more easily compose `Func`s, then sure, give me all the compiler support that can be squeezed out. I currently can't write `collection.Where(Not(PredicateMethodGroup))`, but have to go with `collection.Where(Not(PredicateMethodGroup))`, which is a shame really. – Călin Darie Feb 19 '18 at 06:08
  • @EricLippert From a user's point of view, it seems that if it _can_ be inferred, it _should_ be inferred. There's no reason the compiler can't figure out that the method group contains exactly one method that matches the requirements. From a compiler-dev's point of view, I completely understand that it's probably a narrow case to specially support. However my point is that I don't think any user would feel that adding a second overload "severely changes how type inference works". It would make perfect sense. New overload means types can no longer unambiguous and can't be inferred. That's all. – Clonkex Mar 18 '23 at 00:28
8

I think it's because it's a two-step inference:

  • It has to infer that you want to convert A to a generic delegate

  • It has to infer what the type of the delegate parameter should be

I'm not sure if this is the reason, but my hunch is that a two-step inference isn't necessarily easy for the compiler.

Edit:

Just a hunch, but something is telling me the first step is the problem. The compiler has to figure out to convert to a delegate with a different number of generic parameters, and so it can't infer the types of the parameters.

Community
  • 1
  • 1
user541686
  • 205,094
  • 128
  • 528
  • 886
  • This is sounding right to me. I can do `Test((string a) => {})` and it resolves fine, or Pierre-Alain's example of `Test((Action)A)` and it also works. But why? Is this a limitation of the compiler? A quirk in the rules? Now that I think about it, I haven't ever run into this because 99% of the time I pass lambdas into functions I write like Test, so this problem would never occur. – scobi Jun 03 '11 at 15:52
  • @Scott: I think your first example is really good evidence that this is true; I didn't think of that test. Regarding the "why": I think it's because a two-step inference is normally very hard and time-consuming, and no one thought to special-case this (although I guess that's not too convincing for compiler writers haha, since they have to worry about far worse special cases). – user541686 Jun 03 '11 at 15:58
  • @Scott: Actually, I seem to be wrong -- or else [this first case should have compiled](http://ideone.com/rGyMH), right? – user541686 Jun 03 '11 at 16:07
  • @Scott: Or maybe not -- that's still a two-step conversion, one to infer `StringAction` to be `Action`, one to infer `T` to infer `T` to be `string`... – user541686 Jun 03 '11 at 16:13
5

This looks like a vicious circle to me.

Test method expects a parameter of delegate type constructed from generic type Action<T>. You pass in a method group instead: Test(A). This means compiler has to convert your parameter to a delegate type (method group conversion).

But which delegate type? To know the delegate type we need to know T. We didn't specify it explicitly, so compiler has to infer it to figure out the delegate type.

To infer the type parameters of the method we need to know the types of the method arguments, in this case the delegate type. Compiler doesn't know the argument type and thus fails.

In all other cases either type of argument is apparent:

// delegate is created out of anonymous method,
// no method group conversion needed - compiler knows it's Action<string>
Test((string a) => {});

// type of argument is set explicitly
Test((Action<string>)A);

or type parameter is specified explicitly:

Test<string>(A); // compiler knows what type of delegate to convert A to

P.S. more on type inference

AlexD
  • 5,011
  • 2
  • 23
  • 34
  • 2
    Specifically, neither an anonymous method nor a method group has a type of its own, but an anonymous method causes type inference to do some extra work to utilize the parameter types of the method (§7.5.2.1, 7.5.2.7) whereas a method group (even a method group with only one member) does not. – zinglon Jun 03 '11 at 19:42
2

I could be wrong, but I imagine the real reason C# cannot infer the type is due to method overloading and the ambiguity that arises. For example, suppose I have the following methods: void foo (int) and void foo (float). Now if I write var f = foo. Which foo should the compiler pick? Likewise, the same problem happens with your example using Test(foo).

Thomas Eding
  • 35,312
  • 13
  • 75
  • 106
2

You're passing the name of the Method A. The .Net framework CAN convert it to an Action, but it's implicit and it will not take responsibility for it.

But still, a method name is NOT an explicit Action<> Object. And therefor it won't infer the type as an Action type.

Yochai Timmer
  • 48,127
  • 24
  • 147
  • 185
  • What do you mean by "will not take responsibility for it"? Do you mean that the compiler stops after doing such a conversion and the option is not open for inference at that point? – scobi Jun 03 '11 at 18:34
  • No, I mean that the compiler will not implicitly infer a type from its own conversions. And that is because it can't safely infer what you meant to do (In general, although in this case it might seem obvious). That's why in specific cases (like this) you need to have an explicit cast to tell it what type exactly you meant. – Yochai Timmer Jun 03 '11 at 18:39