21
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".

Michael Liu
  • 52,147
  • 13
  • 117
  • 150
  • I *want* to say it's 13.1.3.2, because `d` is `ICloneable`, and `ICloneable` has a covariant type parameter, and a conversion exists from `Derived` to `Base`, which is why the assignment to `cb` succeeds while still invoking the `new` behavior. But I'm not 100% certain that's the true relevant portion of the spec. – Anthony Pegram Jan 03 '12 at 04:18
  • 4
    Unless Stack Overflow implemented a bat signal specifically for certain members, that summoning will never work! Use the [contact link](http://blogs.msdn.com/b/ericlippert/contact.aspx) on his blog for better results. – Anthony Pegram Jan 03 '12 at 16:27
  • @Anthony Pegram: +1 for 'bat signal' – Tom W Jan 03 '12 at 18:16
  • @AnthonyPegram I think Eric does indeed have a bat signal. – asawyer Jan 03 '12 at 19:06
  • @asawyer: Michael and I actually discussed this question by email some time ago, and he let me know when he posted it here. Anthony is correct; if there is something you want brought to my attention, email me from the blog and I'll look at it if I have free time. – Eric Lippert Jan 03 '12 at 22:00
  • Tbh, I find this not confusin. `b` has its own implementation of `Clone` (provided its not overridden in child class which is the case) and hence `Base.Clone` will be called. But `ICloneable` has no implementation at all, & hence the actual underlyin `Clone` method is called which is `Derived.Clone` (because of *`out` variance*). Even if the call looked like `cb = b; cb.Clone();` I would expect `Derived.Clone` to be called. Of course it can't go that deep if `Derived` itself doesn't implement `ICloneable` which would be the case had there been no `out` for `ICloneable<>`. Good q, +1! – nawfal Nov 29 '13 at 21:44
  • @nawfal: The confusing thing about this behavior is that *it's not supposed to work this way*... at least according to the C# and CLI specifications! – Michael Liu Nov 29 '13 at 21:49
  • @MichaelLiu oh I wasn't aware of that, thanks. I was talking from a logical viewpoint of a layman. – nawfal Nov 30 '13 at 00:11

4 Answers4

15

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#.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
4

It can only have one meaning: the method new public Derived Clone() implements both ICloneable<Base> and ICloneable<Derived>. Only an explicit call to Base.Clone() calls the hidden method.

phoog
  • 42,068
  • 6
  • 79
  • 117
Stefan Steinegger
  • 63,782
  • 15
  • 129
  • 193
  • §13.4.4 says that a class method `A` matches an interface method `B` when the name, type, and formal parameter lists of `A` and `B` are **identical**. Does `Derived.Clone()`, which returns `Derived`, match `ICloneable.Clone()`, which returns `Base`? – Michael Liu Jan 03 '12 at 16:20
0

I think it is because calling:

ICloneable<Base> cb = d;

without variance, then cb can only represent ICloneable<Base>. But with variance, it can also represent ICloneable<Derived>, which is obviously closer and better cast of d than casting to ICloneable<Base>.

Euphoric
  • 12,645
  • 1
  • 30
  • 44
0

It seems to me that the relevant part of the spec would be the one that controls which of two possible implicit reference conversions is in play for the assignment ICloneable<Base> cb = d;. The two choices, taken from section 6.1.6, "implicit reference conversions", are:

  • From any class-type S to any interface-type T, provided S implements T.

(here Derived implements ICloneable<Base>, according to section 13.4, because "when a class C directly implements an interface, all classes derived from C also implement the interface implicitly," and Base directly implements ICloneable<Base>, so Derived implements it implicitly.)

  • From any reference-type to an interface or delegate type T if it has an implicit identity or reference conversion to an interface or delegate type T0 and T0 is variance-convertible (§13.1.3.2) to T.

(Here, Derived is implicitly convertible to ICloneable<Derived> because it implements it directly, and ICloneable<Derived> is variance-convertible to ICloneable<Base>.)

But I can't find any part of the spec that deals with disambiguating implicit reference conversions.

phoog
  • 42,068
  • 6
  • 79
  • 117