What are the kinds of covariance in C#? (Or, covariance: by example)

Question

Covariance is (roughly) the ability to mirror inheritance of \"simple\" types in complex types that use them.
E.g. We can always treat an instance of Cat<

Answer 1

Java employs the concept of use-site variance for generic types: the needed variance is specified at each use site. This is why Java programmers are required to be familiar with the so-called PECS rule. Yes, it is unwieldy and has already received plenty of criticism.

Answer 2

This is best explained in terms of more generic, structural types. Consider:

1. Tuple types: (T1, T2), a pair of types T1 and T2 (or more generally, n-tuples);
2. Function types: T1 -> T2, a function with argument type T1 and result T2;
3. Mutable types: Mut(T), a mutable variable holding a T.

Tuples are covariant in both their component types, i.e. (T1, T2) < (U1, U2) iff T1 < U1 and T2 < U2 (where '<' means is-subtype-of).

Functions are covariant in their result and contravariant in their argument, i.e. (T1 -> T2) < (U1 -> U2) iff U1 < T1 and T2 < U2.

Mutable types are invariant, i.e. Mut(T) < Mut(U) only iff T = U.

All these rules are the most general correct subtyping rules.

Now, an object or interface type like you know it from mainstream languages can be interpreted as a fancy form of tuple containing its methods as functions, among other things. For example, the interface

interface C<T, U, V> {
  T f(U, U)
  Int g(U)
  Mut(V) x
}

essentially represents the type

C(T, U, V) = ((U, U) -> T, U -> Int, Mut(V))

where f, g, and x correspond to the 1st, 2nd, and 3rd component of the tuple, respectively.

It follows from the rules above that C(T, U, V) < C(T', U', V') iff T < T' and U' < U and V = V'. That means that the generic type C is covariant in T, contravariant in U and invariant in V.

Another example:

interface D<T> {
  Int f(T)
  T g(Int)
}

is

D(T) = (T -> Int, Int -> T)

Here, D(T) < D(T') only if T < T' and T' < T. In general, that can only be the case if T = T', so D actually is invariant in T.

There also is a fourth case, sometimes called "bivariance", which means both co- and contravariant at the same time. For example,

interface E<T> { Int f(Int) }

is bivariant in T, because it is not actually used.

Answer 3

Here's what I can think of:

Update

After reading the constructive comments and the ton of articles pointed (and written) by Eric Lippert, I improved the answer:

• Updated the broken-ness of array covariance
• Added "pure" delegate variance
• Added more examples from the BCL
• Added links to articles that explain the concepts in-depth.
• Added a whole new section on higher-order function parameter covariance.

Return type covariance:

Available in Java (>= 5)^[1] and C++^[2], not supported in C# (Eric Lippert explains why not and what you can do about it):

class B {
    B Clone();
}

class D: B {
    D Clone();
}

Interface covariance^[3] - supported in C#

The BCL defines the generic IEnumerable interface to be covariant:

IEnumerable<out T> {...}

Thus the following example is valid:

class Animal {}
class Cat : Animal {}

IEnumerable<Cat> cats = ...
IEnumerable<Animal> animals = cats;

Note that an IEnumerable is by definition "read-only" - you can't add elements to it.
Contrast that to the definition of IList<T> which can be modified e.g. using .Add():

public interface IEnumerable<out T> : ...  //covariant - notice the 'out' keyword
public interface IList<T> : ...            //invariant

Delegate covariance by means of method groups ^[4] - supported in C#

class Animal {}
class Cat : Animal {}

class Prog {
    public delegate Animal AnimalHandler();

    public static Animal GetAnimal(){...}
    public static Cat GetCat(){...}

    AnimalHandler animalHandler = GetAnimal;
    AnimalHandler catHandler = GetCat;        //covariance

}

"Pure" delegate covariance^{[5 - pre-variance-release article]} - supported in C#

The BCL definition of a delegate that takes no parameters and returns something is covariant:

public delegate TResult Func<out TResult>()

This allows the following:

Func<Cat> getCat = () => new Cat();
Func<Animal> getAnimal = getCat; 

Array covariance - supported in C#, in a broken way^{[6] [7]}

string[] strArray = new[] {"aa", "bb"};

object[] objArray = strArray;    //covariance: so far, so good
//objArray really is an "alias" for strArray (or a pointer, if you wish)


//i can haz cat?
object cat == new Cat();         //a real cat would object to being... objectified.

//now assign it
objArray[1] = cat                //crash, boom, bang
                                 //throws ArrayTypeMismatchException

And finally - the surprising and somewhat mind-bending
Delegate parameter covariance (yes, that's co-variance) - for higher-order functions.^[8]

The BCL definition of the delegate that takes one parameter and returns nothing is contravariant:

public delegate void Action<in T>(T obj)

Bear with me. Let's define a circus animal trainer - he can be told how to train an animal (by giving him an Action that works with that animal).

delegate void Trainer<out T>(Action<T> trainingAction);

We have the trainer definition, let's get a trainer and put him to work.

Trainer<Cat> catTrainer = (catAction) => catAction(new Cat());

Trainer<Animal> animalTrainer = catTrainer;  
// covariant: Animal > Cat => Trainer<Animal> > Trainer<Cat> 

//define a default training method
Action<Animal> trainAnimal = (animal) => 
   { 
   Console.WriteLine("Training " + animal.GetType().Name + " to ignore you... done!"); 
   };

//work it!
animalTrainer(trainAnimal);

The output proves that this works:

Training Cat to ignore you... done!

In order to understand this, a joke is in order.

A linguistics professor was lecturing to his class one day.
"In English," he said, "a double negative forms a positive.
However," he pointed out, "there is no language wherein a double positive can form a negative."

A voice from the back of the room piped up, "Yeah, right."

What's that got to do with covariance?!

Let me attempt a back-of-the-napkin demonstration.

An Action<T> is contravariant, i.e. it "flips" the types' relationship:

A < B => Action<A> > Action<B> (1)

Change A and B above with Action<A> and Action<B> and get:

Action<A> < Action<B> => Action<Action<A>> > Action<Action<B>>  

or (flip both relationships)

Action<A> > Action<B> => Action<Action<A>> < Action<Action<B>> (2)     

Put (1) and (2) together and we have:

,-------------(1)--------------.
 A < B => Action<A> > Action<B> => Action<Action<A>> < Action<Action<B>> (4)
         `-------------------------------(2)----------------------------'

But our Trainer<T> delegate is effectively an Action<Action<T>>:

Trainer<T> == Action<Action<T>> (3)

So we can rewrite (4) as:

A < B => ... => Trainer<A> < Trainer<B> 

- which, by definition, means Trainer is covariant.

In short, applying Action twice we get contra-contra-variance, i.e. the relationship between types is flipped twice (see (4) ), so we're back to covariance.