How do covariance and contravariance in method signatures relate to the Liskov Substitution Principle, and what do mainstream languages actually enforce?

## Vocabulary first - **Covariant**: varies *with* the subtyping direction. If `Dog` is a subtype of `Animal`, then position P is covariant when `X<Dog>` (or an override returning `Dog`) is acceptable where `X<Animal>` was expected. - **Contravariant**: varies *against* it. Position P is contravariant when `X<Animal>` is acceptable where `X<Dog>` was expected. - **Invariant**: neither — only the exact type is accepted. - **Override**: a subtype method replacing a supertype method with the same name and compatible signature; calls dispatch dynamically to it. - **Overload**: a *different* method that merely shares a name; selected statically by argument types. Confusing the two is the source of many silent bugs. ## The connection to LSP The Liskov Substitution Principle requires that a subtype not demand more of callers (**preconditions may only weaken**) and not deliver less (**postconditions may only strengthen**). Method-signature variance is exactly what a compiler can mechanically check of that: | Position | Safe direction | LSP rule it encodes | |---|---|---| | Return type | **Covariant** — override may return a narrower type | Postcondition strengthened: caller expecting `Animal` is happy with a `Dog` | | Parameter type | **Contravariant** — override may accept a wider type | Precondition weakened: accepting `Animal` still accepts every `Dog` the caller might pass | | Thrown exceptions | **Covariant** — fewer or narrower | Postcondition strengthened: no new failure modes | Intuition for the parameter case: a machine advertised as "processes `Dog`" can safely be replaced by one that "processes any `Animal`" — anyone bringing a dog is still served. It cannot be replaced by one that only processes `Poodle`, because callers were told any dog would do. A compact way to remember it: **return covariant, parameters contravariant, exceptions covariant.** ## What languages actually enforce - **Covariant return types**: supported by Java (since 5), C#, Kotlin, C++, Scala, TypeScript. Universally the well-known half. - **Contravariant parameter types**: almost nowhere in mainstream OO. Java, C#, Kotlin, and C++ require **invariant** parameter types for an override. Declaring a wider parameter type silently produces an *overload* instead — the classic bug being `boolean equals(MyType other)`, which never overrides `equals(Object)` and so is ignored by collections and hash maps. Java's `@Override` annotation exists largely to catch this. Sather and (partly) Python's structural typing/tooling are among the few environments that model true contravariance. - **Exception narrowing**: enforced in Java for checked exceptions. Unchecked exceptions are unconstrained by the compiler in every mainstream language, so the *behavioural* rule ("no new failure modes") remains a discipline, not a check. - **TypeScript** is deliberately **bivariant** for method parameters (unsound but ergonomic); `strictFunctionTypes` makes standalone function-type parameters contravariant, but method-shorthand declarations stay bivariant for compatibility with common JS patterns. ## Generic type variance — the same rule, one level up For a generic type `Box<T>`, the safe variance depends on how `T` is used: - **Producer → covariant** (`out T` in Kotlin/C#, `? extends T` in Java): only *returns* `T`. `List<Dog>` may be read as `List<out Animal>` because everything it hands you is an `Animal`. - **Consumer → contravariant** (`in T` in Kotlin/C#, `? super T` in Java): only *accepts* `T`. A `Comparator<Animal>` can be used wherever a `Comparator<Dog>` is needed, because it compares any animals including dogs. - **Both → invariant**: a mutable `MutableList<T>` both produces and consumes `T`, so it must be invariant, or you could read a `Cat` out of something you wrote a `Dog` into. The mnemonic is **PECS — Producer Extends, Consumer Super** (Java) or **"out = production, in = consumption"** (Kotlin/C#). It is precisely the same LSP reasoning: a producer only strengthens what it gives, a consumer only weakens what it demands. ## The array covariance counterexample Java and C# make arrays covariant: `Dog[]` is assignable to `Object[]`. This is **unsound** — it permits ``` Object[] objects = new Dog[10]; objects[0] = new Cat(); // compiles; throws ArrayStoreException at runtime ``` Because an array both produces and consumes its element type, it should be invariant. The languages accepted an unsound rule (adding a runtime store check) for pre-generics ergonomics. It's the cleanest evidence that **variance rules are LSP made mechanical, and breaking them relocates the failure to runtime** rather than eliminating it. Generics in both languages are invariant by default precisely to avoid repeating the mistake. ## The hard limit Variance handles only what is expressible in *types*. It cannot express: - "amount must be positive", "the list must be sorted", "the result is never empty" - "this operation is idempotent", "this returns within one millisecond" - "the object is immutable" (the history rule) A subtype can be perfectly variance-legal and grossly LSP-violating — `Square extends Rectangle` has identical signatures throughout. So variance is a *necessary but not sufficient* check; behavioural conformance still needs documentation, assertions, and contract tests run against every implementation. ## Practical takeaways - Use `@Override`/`override` markers everywhere so an accidental overload is a compile error. - Prefer widening a parameter to `Object`/`Any` only when it genuinely means it; a wider parameter with a runtime type check inside is precondition strengthening in disguise. - Apply PECS/`in`/`out` to API generic parameters so callers get maximum flexibility without unsafe casts. - Never rely on array covariance; use generic collections.