Chris Brumme's Weblog

The CLR has two different techniques for implementing interfaces. These two techniques are exposed with distinct syntax in C#:

interface I { void m(); }
class C : I {
   public virtual void m() {} // implicit contract matching
}
class D : I {
   void I.m() {}              // explicit contract matching
}

At first glance, it may seem like the choice between these two forms is a stylistic one. However, there are actually deep semantic differences between the two forms.

(C# has at least one other place where a choice of semantics is encoded in what seems to be a stylistic choice. A class constructor can be expressed in C# either as a static constructor method, or as assignments in a set of static field declarations. Depending on this stylistic choice, the class will or will not be marked with tdBeforeFieldInit. This mark – shown as beforefieldinit in ILDASM – affects the semantics of when the .cctor method will be executed by the CLR. This also results in performance differences, particularly in situations like NGEN or domain-neutral code.)

In class C, we get a public class method ‘m’ that does double duty as the implementation of the interface method. This is all pretty vanilla:

.method public hidebysig newslot virtual instance void  m() cil managed
{
  // Code size       1 (0x1)
  .maxstack  0
  IL_0000:  ret
} // end of method C::m

But in class D, we see something quite different:

.method private hidebysig newslot virtual final instance void  I.m() cil managed
{
  .override I::m
  // Code size       1 (0x1)
  .maxstack  0
  IL_0000:  ret
} // end of method D::I.m

There are several surprising things about this case:

1. The method is introduced (newslot) with the bizarre incantation of virtual, private and final.
2. The name of the method isn’t even ‘m’. It is ‘I.m’.
3. There is a mysterious ‘override’ clause associated with the method body.

The method is marked as virtual because the CLR can only implement interface contracts using virtual members. There’s a bit of a debate on our team whether this is an architectural requirement or an implementation detail. At this point, we’re comfortable that we could remove this restriction without much work. However, we have to consider the ECMA standard, the impact on other CLI implementations like Compact Frameworks, the effect on the various languages targeting the compiler, and some interesting effects on existing applications. We might be saddled with this rule indefinitely.

At the language level, C# allows non-virtuals to implement interface contracts. How do they get around the CLR restriction? Well, if the class that introduces the non-virtual is in the same assembly as the class that uses that method to implement the interface contract, C# quietly defines the base class’ method as virtual. If the base class that introduced the non-virtual is in a different assembly, then C# generates a virtual thunk in the subtype which delegates to the non-virtual base method.

Getting back to our example, I.m is declared as private because it is not available for calling via the class. It can only be called via the interface.

I.m is declared as final because C# really doesn’t want to mark the method as virtual. This was forced on them by the architectural decision / implementation restriction that interface contracts can only be implemented by virtual methods.

As for the name, C# could have picked anything that’s a legal identifier. This member isn’t available for external binding, since it is private to the class and only accessible through the interface.

Since the name ‘I.m’ is insignificant, obviously this isn’t what tells the CLR loader to use this method to satisfy the interface contract. In fact, it’s that mysterious ‘override’ clause. This is what’s known as a MethodImpl. It should not be confused with System.Runtime.CompilerServices.MethodImplAttribute, which controls a method’s eligibility for inlining, its synchronization behavior and other details.

A MethodImpl is a statement in the metadata that matches a method body to a method contract. Here it is used to match the body I.m with the interface contract I::m. Generally, you will see MethodImpls used in this way to match methods to interfaces. But MethodImpls can be used to match any method body to any contract (e.g. a class virtual slot) provided that:

1. The contract is virtual
2. The body is virtual
3. The body and the MethodImpl are defined on the same class
4. The contract is defined either on this class or somewhere up the hierarchy (including implemented interfaces).

Once again, it’s open to debate whether MethodImpls require virtual contracts and bodies for sound architectural reasons or for temporary implementation reasons.

The ECMA spec contains the rules for how interface contracts are satisfied by class methods. This explains how the base class’ layout can be at least partially re-used, and it explains the precedence of the two techniques we’ve seen above (class methods match by name and signature vs. MethodImpls which match methods of any name that have the correct signature).

It also mentions one other surprising detail of interface layout. In the example below, we would expect Derived and Redundant to have the same layout. Sure, there’s a redundant mention of interface I on class Redundant, but that seems irrelevant.

interface I { void m(); }
class A : I {
   public virtual void m() {}
}

class Derived : A {
   public new virtual void m() {}
}

class Redundant : A, I {
   public new virtual void m() {}
}

In fact, it is highly significant. Class A has already satisfied the interface contract for I. Class Derived simply inherits that layout. The new method Derived.m is unrelated to I.m. But in class Redundant, we mention interface I in the implements list. This causes the CLR loader to satisfy the interface contract all over again. In this new layout, Redundant.m can be used to satisfy I.m.

If you’re thinking that some of this stuff is pretty subtle, you are right. Normally, developers wouldn’t concern themselves with the different ways that the CLR can satisfy interface contracts. Instead, you would happily code to your language rules and you would trust your IL generator to spit out the appropriate metadata. In fact, one of the reasons we have all these subtle rules in the CLR is so we can accommodate all the different language rules that we encounter.