Why Invoke method of constructed delegate class is virtual?

I've seen in CLR via C# and in codeproject article Delegate Behind the Scenes that when C# compiler sees this

public delegate void MyDelegate(int intValue);

it actually generates开发者_如何学Go something like this

class MyDelegate : System.MulticastDelegate
{
    public virtual void Invoke(Int32 intValue);

    ...
}

Question is, why Invoke method is virtual? Can this generated delegate type be inherited? From the CLR point of view looks like it can. But why? Why not generating sealed class so there will be no virtual methods lookup penalty at runtime?

This is quacks-like-a-duck typing. Similar kind of typing that makes System.Int32, a value type, derived from ValueType, a reference type. Makes no sense, illegal in C#, but actually behaves that way. The real implementation of a delegate's Invoke method is buried in the CLR and is a static function written in C++.

But sure, annotating it as virtual makes somewhat sense because it behaves like a virtual method. The actual code that executes is not fixed like it is with a non-virtual class method. Even harder to reason out is what the proper model should be for a delegate that's bound to a static method. A virtual method that's static?

It is just a virtual duck.

Reading up on function pointers as used in C could help you get a better mental model for delegates. A delegate is a function pointer with bells on, it can also store the target object. C# lacks the syntax to express this another way.

Here's an interesting quote from Eric Lippert about inheritance in .NET:

I am occasionally asked "but how can a value type, like int, which is 32 bits of memory, no more, no less, possibly inherit from object? An object laid out in memory is way bigger than 32 bits; it's got a sync block and a virtual function table and all kinds of stuff in there." Apparently lots of people think that inheritance has something to do with how a value is laid out in memory. But how a value is laid out in memory is an implementation detail, not a contractual obligation of the inheritance relationship!

There are a number of "special" inherited types in .NET: System.ValueType, System.Enum,System.Void, and System.Delegate, amongst others I'm sure.

Taking a look at the internals of System.Delegate with Reflector.NET I can see a number of calls like this:

[MethodImpl(MethodImplOptions.InternalCall), SecurityCritical]
internal static extern MulticastDelegate InternalAlloc(RuntimeType type);

I suspect that we're dealing with a different implementation detail that doesn't require delegates to use the same virtual look up tables that virtual methods need to use.