Question

interface ICloneable<out T>
{
    T Clone();
}

class Base : ICloneable<Base>
{
    public Base Clone() { return new Base(); }
}

class Derived : Base, ICloneable<Derived>
{
    new public Derived Clone() { return new Derived(); }
}

Given these type declarations, what part of the C# specification explains why the last line of the following code fragment prints “True”? Can developers rely on this behavior?

Derived d = new Derived();
Base b = d;
ICloneable<Base> cb = d;
Console.WriteLine(b.Clone() is Derived); // "False": Base.Clone() is called
Console.WriteLine(cb.Clone() is Derived); // "True": Derived.Clone() is called

Note that if the T type parameter in ICloneable were not declared out, then both lines would print “False”.

Answer 1

It’s complicated.

The call to b.Clone clearly must invoke BC. There is no interface involved here at all! The method to call is determined entirely by compile-time analysis. Therefore it must return an instance of Base. This one is not very interesting.

The call to cb.Clone by contrast is extremely interesting.

There are two things we have to establish to explain the behaviour. First: which "slot" is invoked? Second: what method is in that slot?

An instance of Derived has to have two slots, because there are two methods that must be implemented: ICloneable<Derived>.Clone and ICloneable<Base>.Clone. Let’s call those slots ICDC and ICBC.

Clearly the slot that is invoked by cb.Clone must be the ICBC slot; there is no reason for the compiler to know that slot ICDC even exists on cb, which is of type ICloneable<Base>.

What method goes in that slot? There are two methods, Base.Clone and Derived.Clone. Let’s call those BC and DC. As you have discovered, the contents of that slot on an instance of Derived is DC.

This seems odd. Clearly the contents of slot ICDC must be DC, but why should the contents of slot ICBC also be DC? Is there anything in the C# specification which justifies this behaviour?

The closest we get is section 13.4.6, which is about "interface re-implementation". Briefly, when you say:

class B : IFoo 
{
    ...
}
class D : B, IFoo
{
    ...
}

then as far as methods of IFoo are concerned, we start from scratch in D. Anything that B has to say about what methods of B map to methods of IFoo is discarded; D might choose the same mappings as B did, or it might choose completely different ones. This behaviour can lead to some unanticipated situations; you can read more about them here:

http://blogs.msdn.com/b/ericlippert/archive/2011/12/08/so-many-interfaces-part-two.aspx

But: is an implementation of ICloneable<Derived> a re-implementation of ICloneable<Base>? It is not at all clear that it should be. The interface re-implementation of IFoo is a re-implementation of every base interface of IFoo, but ICloneable<Base> is not a base interface of ICloneable<Derived>!

To say that this is an interface re-implementation would certainly be a stretch; the specification does not justify it.

So what is going on here?

What is going on here is the runtime needs to fill in the slot ICBC. (As we have already said, slot ICDC clearly must get method DC.) The runtime thinks that this is an interface re-implementation, so it does so by searching from Derived to Base, and does a first-fit match. DC is a match thanks to variance, so it wins out over BC.

Now you might well ask where that behaviour is specified in the CLI specification, and the answer is "nowhere". In fact, the situation is considerably worse than that; a careful reading of the CLI specification shows in fact that the opposite behaviour is specified. Technically the CLR is out of compliance with its own specification here.

However, consider the exact case that you describe here. It is reasonable to suppose that someone who calls ICloneable<Base>.Clone() on an instance of Derived wants to get a Derived back out!

When we added variance to C# we of course tested the very scenario you mention here and eventually discovered that the behaviour was both unjustified and desirable. There then followed a period of some negotiation with the keepers of the CLI specification as to whether or not we should edit the specification such that this desirable behaviour would be justified by the spec. I do not recall what the outcome of that negotiation was; I was not personally involved in it.

So, summing up:

• De facto, the CLR does a first-fit match searching from derived to base, as though this were an interface re-implementation.
• De jure, that’s not justified by either the C# specification or the CLI specification.
• We can’t change the implementation without breaking people.
• Implementing interfaces that unify under variance conversions is dangerous and confusing; try to avoid it.

For another example of where variant interface unification exposes an unjustified, implementation-dependent behaviour in the CLR’s "first fit" implementation, see:

http://blogs.msdn.com/b/ericlippert/archive/2007/11/09/covariance-and-contravariance-in-c-part-ten-dealing-with-ambiguity.aspx

And for an example in which non-variant generic unification of interface methods exposes an unjustified, implementation-dependent behaviour in the CLR’s "first fit" implementation, see:

https://ericlippert.com/2006/04/05/odious-ambiguous-overloads-part-one/
https://ericlippert.com/2006/04/06/odious-ambiguous-overloads-part-two/

In that case you can actually cause a change in program behaviour by re-ordering the text of a program, which is truly bizarre in C#.