Why can I cast the invariance of IList<T> away?

Question

Currently I'm preparing a presentation of the new generic variance features in C# for my colleagues. To cut the story short I wrote following lines:

IList<Form> formsList = new List<Form> { new Form(), new Form() };
IList<Control> controlsList = formsList;

Yes, this is of course not possible, as IList(Of T) is invariant (at least my thought). The compiler tells me that:

Cannot implicitly convert type System.Collections.Generic.IList<System.Windows.Forms.Form> to System.Collections.Generic.IList<System.Windows.Forms.Control>. An explicit conversion exists (are you missing a cast?)

Hm, does this mean I can force an explicit conversion? I just tried it:

IList<Form> formsList = new List<Form> { new Form(), new Form() };
IList<Control> controlsList = (IList<Control>)formsList;

And… it compiles! Does it mean I can cast the invariance away? - At least the compiler is ok with that, but I just turned the former compile time error to a run time error:

Unable to cast object of type 'System.Collections.Generic.List`1[System.Windows.Forms.Form]' to type 'System.Collections.Generic.IList`1[System.Windows.Forms.Control]'.

My question(s): Why can I cast the invariance of IList<T> (or any other invariant interface as to my experiments) away? Do I really cast the invariance away, or what kind of conversion happens here (as IList(Of Form) and IList(Of Control) are completely unrelated)? Is this a dark corner of C# I didn't know?

Tabbie

+1 for interest. I have no idea as to the answer :-) – Afoul

Hi GilShalit! I guess Ani got the point! - So simple... – Tabbie

Answer 1

Essentially, a type could implement IList<Control> as well as IList<Form> so it's possible for the cast to succeed - so the compiler lets it through for the time being (aside: it could potentially be smarter here and produce a warning because it knows the concrete type of the referenced object, but doesn't. I don't think it would be appropriate to produce a compiler-error since it is not a breaking change for a type to implement a new interface).

As an example of such a type:

public class EvilList : IList<Form>, IList<Control> { ... }

What happens at run-time is just a CLR type-check. The exception you are seeing is representative of a failure of this operation.

The IL generated for the cast is:

castclass [mscorlib]System.Collections.Generic.IList`1<class [System.Windows.Forms]System.Windows.Forms.Control>

From MSDN:

The castclass instruction attempts to cast the object reference (type O) atop the stack to a specified class. The new class is specified by a metadata token indicating the desired class. If the class of the object on the top of the stack does not implement the new class (assuming the new class is an interface) and is not a derived class of the new class then an InvalidCastException is thrown. If the object reference is a null reference, castclass succeeds and returns the new object as a null reference.

InvalidCastException is thrown if obj cannot be cast to class.

Burnejones

Aha another kind of conversion...! The run time error is clear to me so far. Yes, C#'s behavior is clear to me now. Thanks a lot! – Tabbie

More generally, for the reason you identity, it is always legal to cast an expression of one interface type to a different interface type. The compiler has no idea whether there does or does not exist an object that implements both interfaces. Remember that a cast means "I know more than you, compiler; I guarantee that this will work out at runtime". If you do not know for certain that it will work out at runtime then do not use a cast! Use the "is" and "as" operators instead. – Gothicism

Hi Eric! Yes, I use the "cast is a contact lens you put on the compiler" metaphor myself very often... I was just too blind to see what's going on here... maybe I deserved rather a downvote! – Tabbie

@Eric: For the "unknown interface instance -> different interface" case, I agree. But in this case, since the compiler knows that the object is a List<Form>, couldn't it at least warn? Or at least for the simpler case of (IList<Control>)List<Form>. Something like "Based on available meta-data, this cast is going to fail." Would this be inappropriate / very hard to work into the compiler? – Burnejones

@Burnejones Metadata isn't good enough; it would need to evaluate arbitrary expressions to determine the actual runtime-type to do what you want. For example, what happens if I derive a class from List<T> called EvilList<T> which does implement IList<Control>? Then the cast works, but the compiler can't know that just based on the compile-time type of the variable. – Ever

@Burnejones In theory, if the type was sealed, then the compiler could do what you're talking about, since then the metadata on the compile-type would be sufficient to rule out the conversion. – Ever

@dlev: I am talking of the specific case when the compiler knows the run-time type of the object, example: (IList<Control>) (new List<Form>()). I'm not bringing inheritance into the picture :). Also, I am only asking for a warning since (stretching things) the user may be writing this with the expectation that a binary-compatible assembly containing the type be swapped in where it does implement the target interface. – Burnejones

@Burnejones Fair point; there are some optimizations around that (e.g. new object().ToString() elides the null-check). I guess this wasn't deemed important/useful enough. – Ever

Answer 2

I would suspect in this case you would throw a run-time exception if you tried to add a new TextBlock into your controlsList. The TextBlock would conform to the contract of the controlsList but not the formsList.

IList<Form> formsList = new List<Form> { new Form(), new Form() }; 
IList<Control> controlsList = (IList<Control>)formsList; 
controlsList.Add(New TextBlock); // Should throw at runtime.

Type safe invarience typically rears its head as a runtime exception in this case. In this case, you might be safe to declare the controlsList as IEnumerable rather than IList (assuming .Net 4.0) because IEnumerable is declared as covariant (IEnumerable). This solves the problem of trying to add a wrong type to the controls list because .Add (and other input methods) aren't available from the out interface.

Twirp