object[] arr = new string[3]; arr[0] = 42; compiles cleanly and throws at runtime. That single line is a 25-year-old wart baked into the CLR — and understanding exactly why it's unsafe is what makes covariant generics finally click.

You know from Intermediate that IEnumerable<Dog> can widen to IEnumerable<Animal>, and IComparer<Animal> can narrow to IComparer<Dog>. You know out and in are the annotations that make each one legal. What that lesson deliberately deferred was the actual proof of why those rules are sound — and a genuinely surprising fact: C# already had a covariance-like feature before generics even existed, and it's unsound. It's called array covariance, it's still in the language today for backward compatibility, and it can throw a runtime exception from code that looks completely unremarkable.

In this lesson: the formal reasoning behind why out/read-only positions are safe and a hypothetical covariant IList<out T> would not be, array covariance as a real (and non-generic) legacy safety hole, writing your own variant interface, and the precise scope of where variance does and doesn't apply in C#.

What Is It?

The Quick Recap

Covariance (out T) lets a more derived type argument substitute for a less derived one — IEnumerable<Dog> is an IEnumerable<Animal>. Contravariance (in T) works the other direction — IComparer<Animal> is an IComparer<Dog>. Both only apply to generic interfaces and delegates, never classes or structs.

The Precise Reason: Positions, Not Vibes

The rule isn't "covariance is for reading, contravariance is for writing" as a rough intuition — it's a provable, structural fact about where T is allowed to appear in a member's signature:

• Output position — a return type, or an out parameter. The member produces a T for the caller.
• Input position — an ordinary (or in) parameter. The member consumes a T supplied by the caller.

A generic interface can only be marked out T if every single member, across the entire interface, uses T exclusively in output positions. The compiler checks this exhaustively at the interface declaration — not by convention, but as a hard compile-time rule. That's what makes the resulting variance provably safe rather than merely "usually fine."

Why Does It Exist?

The Problem — A Real Precedent for What Happens Without the Rule

C# didn't invent this caution from nothing — it had already shipped an unsafe version of covariance once, for arrays, back in C# 1.0, before generics existed at all (added in C# 2.0). Arrays have always allowed a derived-to-base widening conversion with no restriction on read vs. write positions:

string[] strings = new string[3];
object[] objects = strings;      //  compiles — arrays are covariant, unconditionally

objects[0] = 42;                 //  ALSO compiles — object[] accepts any object, including an int (boxed)
//  ArrayTypeMismatchException at runtime — the actual array is a string[], and 42 isn't a string

This is real, documented, and still true in current .NET — arrays are covariant for every reference-element-type array, with no out/in-style restriction, and the CLR only catches the violation with a runtime type check on every array-element write, not at compile time.

The Need

When generics arrived in C# 2.0, and generic variance in C# 4.0, the language designers had exactly this precedent as a cautionary example. They needed a way to offer the genuine convenience of covariance/contravariance without repeating the array mistake — a rule that could be checked and proven safe entirely at compile time, with zero runtime type-checking overhead and zero possibility of a runtime type-mismatch exception.

The Solution

Restrict variance to generic interfaces and delegates (which have no storage of their own — only a contract), and require the direction-of-use rule (output-only for out, input-only for in) to be checked exhaustively at the interface's declaration. Where arrays trade a compile-time guarantee for a runtime check that can fail, generic interface variance makes the unsafe case simply not compile in the first place — IList<T>, which both reads and writes T, cannot be marked out or in at all, so the array bug's generic equivalent is caught before the program ever runs.

Big Picture

How It Works

// A read-only "factory" abstraction — only ever produces a T
public interface IProducer<T>
{
    T Produce();
}

public interface IProducer<out T>
{
    T Produce(); //  compiles — T only ever appears in an output position
}

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

IProducer<Dog> dogProducer = new DogProducer();
IProducer<Animal> animalProducer = dogProducer; //  covariance — widening is safe

public interface IConsumer<in T>
{
    void Consume(T item); // T only ever an input — legal for 'in'
}

public class AnimalConsumer : IConsumer<Animal> { public void Consume(Animal a) { } }

IConsumer<Animal> animalConsumer = new AnimalConsumer();
IConsumer<Dog> dogConsumer = animalConsumer; //  contravariance — narrowing is safe

Simple Example

Reproducing the array covariance hole exactly, then showing why the generic equivalent can't happen:

//  Arrays: this compiles, and blows up at runtime
public class Animal { }
public class Dog : Animal { }
public class Cat : Animal { }

Animal[] animals = new Dog[3]; // legal — array covariance, no restriction at all
animals[0] = new Cat();        // compiles! Cat IS an Animal, as far as the compiler can see
//  System.ArrayTypeMismatchException at runtime — the real array only holds Dogs

//  Generics: the equivalent mistake simply cannot compile
List<Dog> dogs = new List<Dog>();
// List<Animal> genericAnimals = dogs;  //  compile error — List<T> is invariant, full stop
// IList<Animal> also would not compile — IList<T> has no out/in annotation, for the same reason
IEnumerable<Animal> readOnlyView = dogs; //  fine — IEnumerable<out T> is read-only, provably safe

Meaning: The array version trades a compile-time guarantee for a runtime check that can fail in production. The generic interface version refuses to compile the moment you'd need write access through a widened reference — the mistake is caught before the program ever runs.

Real-World Example

A notification pipeline is a natural home for both directions of variance at once — a read-only source of events (covariant) and a general-purpose handler that should work for more specific event types too (contravariant).

public class Notification { public string Message { get; init; } = ""; }
public class OrderShippedNotification : Notification { public int OrderId { get; init; } }

// Covariant source — only ever hands notifications OUT
public interface INotificationSource<out T> where T : Notification
{
    T GetNext();
}

// Contravariant handler — only ever accepts notifications IN
public interface INotificationHandler<in T> where T : Notification
{
    void Handle(T notification);
}

public class OrderShippedSource : INotificationSource<OrderShippedNotification>
{
    public OrderShippedNotification GetNext() => new() { Message = "Shipped", OrderId = 42 };
}

public class GeneralNotificationHandler : INotificationHandler<Notification>
{
    public void Handle(Notification n) => Console.WriteLine($"Logging: {n.Message}");
}

// Usage — both directions of variance doing real work:
INotificationSource<OrderShippedNotification> shippedSource = new OrderShippedSource();
INotificationSource<Notification> genericSource = shippedSource; //  covariance

INotificationHandler<Notification> generalHandler = new GeneralNotificationHandler();
INotificationHandler<OrderShippedNotification> shippedHandler = generalHandler; //  contravariance

shippedHandler.Handle(shippedSource.GetNext()); // "Logging: Shipped"

The general-purpose handler, written once against the base Notification type, is reusable for any specific notification subtype without writing per-subtype handlers — exactly the kind of design variance is meant to enable.

Analogy

Under the Hood

Common Confusion

1. "If arrays can be covariant unconditionally, why can't List<T>?" — arrays chose convenience over safety, once, before the tools to do better existed

Array covariance isn't proof that unconditional covariance is fine — it's a documented, acknowledged design compromise from before C# had a safer alternative, kept today only for backward compatibility. Generic variance was designed after this lesson had already been learned, which is exactly why it's restricted to the provably-safe cases.

2. Variance is about generic interfaces/delegates specifically — not "generics" as a blanket category

A generic class or struct is always invariant, with no way to opt in, regardless of how you use its type parameter internally. Variance is a feature of the interface/delegate contract system specifically, not of generics in general — this is worth restating because it's easy to over-generalize "generics can be variant" into "any generic type can be variant."

3. The runtime ArrayTypeMismatchException check has a real, if small, performance cost

Because array covariance can't be verified at compile time, every write to a reference-type array element goes through an implicit runtime type check (a "covariant array store check") to catch exactly the scenario shown above. It's usually negligible, but it is genuinely extra work the CLR performs on every such write — one more reason the interface-variance design, needing zero such checks, is the better long-term model.

Common Mistakes

Mistake 1 — Widening an array reference and then writing through it

void PopulateWithDefault(object[] items, object defaultValue)
{
    for (int i = 0; i < items.Length; i++) items[i] = defaultValue;
}

string[] names = new string[5];
PopulateWithDefault(names, "N/A"); // fine — "N/A" is a string
PopulateWithDefault(names, 42);    //  ArrayTypeMismatchException — 42 isn't a string

Avoid designing APIs that accept a covariant array reference for writing at all; accept the specific element type, or use a generic method constrained appropriately, so the compiler — not a runtime exception — catches the mistake.

Mistake 2 — Trying to force a mixed read/write interface to be variant

public interface IRepository<out T>   //  compile error
{
    T GetById(int id);
    void Add(T item);   // T as an input — violates 'out'
}

Split responsibilities into a read-only, genuinely covariant interface and a separate read/write (invariant) interface if you need both — don't fight the compiler on this; the error is telling you the design itself is unsafe as a single variant contract, exactly as it should.

Mistake 3 — Assuming a covariant interface reference is somehow "read-only" at the object level

Believing that once you have an IEnumerable<Animal> view over a List<Dog>, the underlying list itself becomes immutable. Variance only restricts what's reachable through that specific reference — if you still hold the original List<Dog> reference elsewhere, it remains fully mutable through that reference; nothing about the object itself changed.

When Should I Use It?

• Design your own generic interface as covariant (out T) when it's genuinely read-only shaped — a source, a factory, a producer that only ever hands back T.
• Design your own generic interface as contravariant (in T) when it's genuinely a sink or handler — something that only ever consumes a T supplied to it, like a comparer, a validator, or an event handler.
• Never fight the compiler to force variance onto an interface with mixed read/write members — split the interface instead, as shown in "Common Mistakes."
• Avoid designing new APIs that accept a covariant array parameter for writing — prefer List<T>/generic collections and methods where the compiler, not ArrayTypeMismatchException, catches a type mistake.

Mental Model

Key Takeaway

Check Your Understanding

You've seen the formal reasoning behind variance safety, the legacy array covariance hole, and how to write your own variant interfaces. Let's check your understanding.

You now understand not just that variance works, but exactly why it's provably safe — and you've seen the real, historical counter-example that makes the contrast concrete.

dotnetmadeeasy.com — Learn C# and .NET, the right way.