Maybe this will make it clearer:
public class SomeClass
{
static void foo(int x) { }
static void foo(string s) { }
static void bar<T>(Action<T> f){}
static void barz(Action<int> f) { }
static void test()
{
Action<int> f = foo;
bar(f);
barz(foo);
bar(foo);
//these help the compiler to know which types to use
bar<int>(foo);
bar( (int i) => foo(i));
}
}
foo is not an action – foo is a method group.
- In the assignment statement, the compiler can tell clearly which foo you’re talking about, since the int type is specified.
- In the barz(foo) statement, the compiler can tell which foo you’re talking about, since the int type is specified.
- In the bar(foo) statement, it could be any foo with a single parameter – so the compiler gives up.
Edit: I’ve added two (more) ways to help the compiler figure out the type (ie – how to skip the inference steps).
From my reading of the article in JSkeet’s answer, the decision to not infer the type seems to be based on a mutual infering scenario, such as
static void foo<T>(T x) { }
static void bar<T>(Action<T> f) { }
static void test()
{
bar(foo); //wut's T?
}
Since the general problem was unsolve-able, they choose to left specific problems where a solution exists as unsolved.
As a consequence of this decision, you won’t be adding a overload for a method and getting a whole lot of type confusion from all the callers that are used to a single member method group. I guess that’s a good thing.