Covariance and Contravariance with C# Arrays [dupl

Question

This question already has an answer here:

• Covariance and contravariance real world example 8 answers

While reading a section of an article about covariance and contravariance at Wikipedia, I ran into the following, bolded sentence:

First consider the array type constructor: from the type Animal we can make the type Animal[] ("array of animals"). Should we treat this as

• Covariant: a Cat[] is a Animal[]
• Contravariant: a Animal[] is a Cat[]
• or neither (invariant)?

If we wish to avoid type errors, and the array supports both reading and writing elements, then only the third choice is safe. Clearly, not every Animal[] can be treated as if it were a Cat[], since a client reading from the array will expect a Cat, but an Animal[] may contain e.g. a Dog. So the contravariant rule is not safe.

Conversely, a Cat[] can not be treated as a Animal[]. It should always be possible to put a Dog into a Animal[]. With covariant arrays this can not be guaranteed to be safe, since the backing store might actually be an array of cats. So the covariant rule is also not safe—the array constructor should be invariant. Note that this is only a issue for mutable arrays; the covariant rule is safe for immutable (read-only) arrays.

I understand the concept; I just want an example of how this "cannot be guaranteed to be safe" in C#.

Answer 1

I think what they're trying to say is:

Dog dog = new Dog();
Cat[] cats = new Cat[] { catOne, catTwo, catThree };
Animal[] animals = cats;
animals.Add(dog);

Line 3 of this code cannot be legal because you SHOULD always be able to do line 4 (Adding a Dog to an array of Animals). But if line 3 was legal, then line 4 would not be legal (because you can't add a Dog to an array of Cats).

Answer 2

It's not safe at compile time. In other words, there's code which is legal by the language rules, but fails at execution time, without any explicit casting to give a big warning sign of "this might fail". The CLR makes sure that only valid writes succeed at execution time. For example:

string[] strings = new string[1];
object[] objects = strings;
objects[0] = new object();

That will throw an exception (ArrayTypeMismatchException) at execution time. The alternative would have been to allow it at execution time, at which point strings[0] would have been a reference to a non-string object, which would clearly be bad.

See also recent blog posts:

• One by me about performance and safety using a generic wrapper
• One on immutable arrays from the BCL team
• Part 2 of Eric Lippert's blog series on variance in general (the series is mostly aimed at generics, but this part is on arrays)