Covariance and Contravariance with C# Arrays [duplicate]

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

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.

Covariance and Contravariance with C# Arrays [duplicate]

Related

Recent Posts