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.
When the return type is not void as above in my case it is int. Methods with Int return types are added to the delegate instance and will be executed as per the addition sequence but the variable that is holding the return type value will have the value return from the method that is executed at the end.
Delegates can be invoke like a normal function or Invoke() method. Multiple methods can be assigned to the delegate using "+" or "+=" operator and removed using "-" or "-=" operator. It is called multicast delegate. If a multicast delegate returns a value then it returns the value from the last assigned target method.
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, e.g.
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!
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With