As you note,
IList<T> is not covariant. As a rule of thumb: any class that can modify its state cannot be covariant. The reason is that such classes often have methods that have
T as the type of one of their parameters, e.g.
void Add(T element). And covariant type parameters are not allowed in input positions.
Generics were added, among other reasons, to provide type safety. For example, you can't add an
Elephant to a list of
ICollection<T> were to extend
ICollection, then you could call
((ICollection)myApples).Add(someElephant) without a compile-time error, as
ICollection has a method
void Add(object obj), which seemingly allows you to add any object to the list, while in practice you can only add objects of
ICollection<T> does not extend
IList<T> does not extend
Anders Hejlsberg, one of the creators of C#, explains it like this:
Ideally all of the generic collection interfaces (e.g. ICollection, IList) would inherit from their non-generic counterparts such that generic interface instances could be used both with generic and non-generic code.
As it turns out, the only generic interface for which this is possible is IEnumerable, because only IEnumerable is contra-variant: In IEnumerable, the type parameter T is used only in "output" positions (return values) and not in "input" positions (parameters). ICollection and IList use T in both input and output positions, and those interfaces are therefore invariant.
Since .Net 4.5 there are the
IReadOnlyCollection<out T> and
IReadOnlyList<out T> covariant interfaces. But
ICollection<T> and many of the list and collection classes don't implement or extend them. Frankly, I find them not very useful, as they only define
If I could redesign .Net 4.5 from the ground up, I would have split the list interface into a read-only covariant interface
IList<out T> that includes
IndexOf, and a mutable invariant interface
IMutableList<T>. Then you could cast
IList<object>. I implemented this here:
M42 Collections - Covariant collections, lists and arrays.