While investigating this question I got curious about how the new covariance/contravariance features in C# 4.0 will affect it.
In Beta 1, C# seems to disagree with the CLR. Back in C# 3.0, if you had:
public event EventHandler<ClickEventArgs> Click;
... and then elsewhere you had:
button.Click += new EventHandler<EventArgs>(button_Click);
... the compiler would barf because they're incompatible delegate types. But in C# 4.0, it compiles fine, because in CLR 4.0 the type parameter is now marked as in, so it is contravariant, and so the compiler assumes the multicast delegate += will work.
Here's my test:
public class ClickEventArgs : EventArgs { }
public class Button
{
public event EventHandler<ClickEventArgs> Click;
public void MouseDown()
{
Click(this, new ClickEventArgs());
}
}
class Program
{
static void Main(string[] args)
{
Button button = new Button();
button.Click += new EventHandler<ClickEventArgs>(button_Click);
button.Click += new EventHandler<EventArgs>(button_Click);
button.MouseDown();
}
static void button_Click(object s, EventArgs e)
{
Console.WriteLine("Button was clicked");
}
}
But although it compiles, it doesn't work at runtime (ArgumentException: Delegates must be of the same type).
It's okay if you only add either one of the two delegate types. But the combination of two different types in a multicast causes the exception when the second one is added.
I guess this is a bug in the CLR in beta 1 (the compiler's behaviour looks hopefully right).
Update for Release Candidate:
The above code no longer compiles. It must be that the contravariance of TEventArgs in the EventHandler<TEventArgs> delegate type has been rolled back, so now that delegate has the same definition as in .NET 3.5.
That is, the beta I looked at must have had:
public delegate void EventHandler<in TEventArgs>(object sender, TEventArgs e);
Now it's back to:
public delegate void EventHandler<TEventArgs>(object sender, TEventArgs e);
But the Action<T> delegate parameter T is still contravariant:
public delegate void Action<in T>(T obj);
The same goes for Func<T>'s T being covariant.
This compromise makes a lot of sense, as long as we assume that the primary use of multicast delegates is in the context of events. I've personally found that I never use multicast delegates except as events.
So I guess C# coding standards can now adopt a new rule: don't form multicast delegates from multiple delegate types related through covariance/contravariance. And if you don't know what that means, just avoid using Action for events to be on the safe side.
Of course, that conclusion has implications for the original question that this one grew from...