📝 Lesson 1.1: Generic Variance and Advanced Constraints

The Variance Puzzle

Given a class hierarchy where Dog derives from Animal (Intermediate/OOP), it feels natural that "a sequence of dogs is a sequence of animals." And indeed:

IEnumerable<Dog> dogs = new List<Dog> { new Dog(), new Dog() };
IEnumerable<Animal> animals = dogs;   // ✅ allowed — IEnumerable is covariant

But this closely-related assignment is a compile error:

List<Dog> dogList = new List<Dog>();
List<Animal> animalList = dogList;    // ❌ error — List is invariant

There are three cases, and the difference comes down to what the type does with T — produce it, consume it, or both:

Covariance (out)

Covariance lets a generic type flow in the same direction as its type argument: because Dog is an Animal, an IEnumerable<Dog> is usable as an IEnumerable<Animal>. It's marked with out on the type parameter.

Look at the actual .NET declaration:

public interface IEnumerable<out T> : IEnumerable   // note: out T
{
    IEnumerator<T> GetEnumerator();
}

The out is a promise: "T only ever comes out of this interface (as return values), never goes in (as parameters)." That's what makes it safe — every Dog that comes out is a valid Animal, so treating the sequence as IEnumerable<Animal> can never break.

Contravariance (in)

Contravariance is the mirror image: the generic type flows in the opposite direction of its type argument. It applies to types that only consume T as input, and is marked with in.

Consider IComparer<in T>, which compares two T values (input only):

public interface IComparer<in T>   // note: in T
{
    int Compare(T x, T y);
}

Here's the mind-bending but logical part: a comparer that can compare any Animal can certainly compare two Dogs. So an IComparer<Animal> is usable as an IComparer<Dog> — the reverse of covariance:

IComparer<Animal> animalComparer = new AnimalComparer();
IComparer<Dog> dogComparer = animalComparer;   // ✅ contravariance (in)

💡 Remember it as PECS-in-C#: out = comes out = producer = covariant. in = goes in = consumer = contravariant. The keyword literally tells you the direction T travels.

Invariance and Safety

A type that both accepts and returns T can't be safely varied in either direction — it's invariant. List<T> is the classic example: you can add a T (input) and read a T (output).

Here's why allowing List<Dog> → List<Animal> would be dangerous:

List<Dog> dogs = new List<Dog>();
List<Animal> animals = dogs;      // IF this were allowed...
animals.Add(new Cat());           // ...you could add a Cat to a list of Dogs! 💥

That would let a Cat sneak into a List<Dog>, breaking type safety. To prevent exactly this, List<T> is invariant — the compiler forbids the assignment in the first place.

Declaring Your Own Variance

You can add variance to your own generic interfaces and delegates when it makes sense. Suppose a read-only producer interface:

// Covariant: T only appears as a return value
public interface IProducer<out T>
{
    T Produce();
}

public class DogProducer : IProducer<Dog>
{
    public Dog Produce() => new Dog();
}

// Because of 'out', this assignment now works:
IProducer<Animal> animalProducer = new DogProducer();
Animal a = animalProducer.Produce();   // ✅

And a consumer interface, which can be contravariant:

// Contravariant: T only appears as a parameter
public interface IConsumer<in T>
{
    void Consume(T item);
}

IConsumer<Animal> animalConsumer = new AnimalConsumer();
IConsumer<Dog> dogConsumer = animalConsumer;   // ✅

Advanced Constraints

You met basic constraints (where T : IComparable<T>, : class, : new()) in Intermediate. Here are the more advanced options and combinations:

Constraints combine and stack. Order matters: a base class comes first, then interfaces, then new() last:

public T CreateAndTag<T>(string tag)
    where T : Entity, ITaggable, new()
{
    T item = new T();          // allowed by new()
    item.Tag = tag;            // allowed by ITaggable
    return item;               // T is an Entity, guaranteed
}

Multiple type parameters can each have their own constraints:

public TResult Map<TSource, TResult>(TSource source, Func<TSource, TResult> f)
    where TSource : notnull
    where TResult : class
{
    return f(source);
}

Exercise & Quiz

class Animal { public string Name { get; set; } = "?"; }
class Dog : Animal { }

interface IReadRepository<out T>
{
    T GetFirst();
}

interface IWriter<in T>
{
    void Write(T item);
}

// TODO: implement DogRepository and AnimalWriter, then do the variant assignments

class Animal { public string Name { get; set; } = "?"; }
class Dog : Animal { }

interface IReadRepository<out T>
{
    T GetFirst();
}

interface IWriter<in T>
{
    void Write(T item);
}

class DogRepository : IReadRepository<Dog>
{
    public Dog GetFirst() => new Dog { Name = "Rex" };
}

class AnimalWriter : IWriter<Animal>
{
    public void Write(Animal item) => Console.WriteLine($"Writing {item.Name}");
}

// Covariance: a Dog-producer IS an Animal-producer (every Dog it returns is an Animal)
IReadRepository<Animal> repo = new DogRepository();
Animal a = repo.GetFirst();
Console.WriteLine(a.Name);          // Rex

// Contravariance: an Animal-consumer IS a Dog-consumer (it can handle any Dog)
IWriter<Dog> writer = new AnimalWriter();
writer.Write(new Dog { Name = "Buddy" });   // Writing Buddy

Summary

📚 Additional Resources

• Covariance and contravariance — Microsoft Docs
• Constraints on type parameters
• Variance in generic interfaces

🚀 What's Next?

You've deepened your command of the type system. Next, we make APIs a joy to use. In Lesson 1.2: Extension Methods and Fluent APIs, you'll add methods to existing types and design chainable, readable interfaces.