The difference between implicit and explicit delegate creation (with and without generics)

Question

See the four lines in the Go() method below:

delegate void Action<T>(T arg);
delegate void Action();

void DoSomething<T>(Action<T> action)
{
    //...
}

void DoSomething(Action action)
{
    //...
}

void MyAction<T>(T arg)
{
    //...
}

void MyAction()
{
    //...
}

void Go<T>()
{
    DoSomething<T>(MyAction<T>); // throws compiler error - why?
    DoSomething(new Action<T>(MyAction<T>)); // no problems here
    DoSomething(MyAction); // what's the difference between this...
    DoSomething(new Action(MyAction)); // ... and this?
}

Note that the compiler error generated by the first call is: The type arguments for method 'Action(T)' cannot be inferred from the usage. Try specifying the type arguments explicitly.

Answer 1

There's no difference between MyAction and new Action(MyAction) (when they're both valid) other than the former won't work in C# 1. This is an implicit method group conversion . There are times that this isn't applicable, most notable when the compiler can't work out what kind of delegate you want, eg

Delegate foo = new Action(MyAction); // Fine
Delegate bar = MyAction; // Nope, can't tell target type

This comes into play in your question because both of the methods involved are overloaded. This leads to headaches, basically.

As for the generics side - it's interesting. Method groups don't get much love from C# 3 type inference - I'm not sure whether that's going to be improved in C# 4 or not. If you call a generic method and specify the type argument, type inference works fairly well - but if you try to do it the other way round, it fails:

using System;

class Test
{
    static void Main()
    {
        // Valid - it infers Foo<int>
        DoSomething<int>(Foo);
        // Valid - both are specified
        DoSomething<int>(Foo<int>);
        // Invalid - type inference fails
        DoSomething(Foo<int>);
        // Invalid - mismatched types, basically
        DoSomething<int>(Foo<string>);
    }

    static void Foo<T>(T input)
    {
    }

    static void DoSomething<T>(Action<T> action)
    {
        Console.WriteLine(typeof(T));
    }
}

Type inference in C# 3 is very complicated, and works well in most cases (in particular it's great for LINQ) but fails in a few others. In an ideal world, it would become easier to understand and more powerful in future versions... we'll see!

Answer 2

The non-generic implicit delegate creation is just syntactic sugar, so the compiler generates exactly the same code for

DoSomething(MyAction);

and

DoSomething(new Action(MyAction));

as it can infer the type of the delegate directly from the method arguments & context.

With the generic delegate, you have to specify the delegate type due to covariance and contravariance (see http://msdn.microsoft.com/en-us/library/ms173174(VS.80).aspx for details) - the T in Action can be a supertype to the T in the method, and it will still be accepted as a delegate method. So, you need to specify the T in the delegate explicitly as the compiler can't figure it out itself.

Answer 3

Just a sidenote.. For some reason this works in VB.

Seems the implementation of the preprocessor in C# and VB differ when i comes to converting the Methodgroup / adderessof to a delegate.