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?

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.

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.