La variance, ou dans quel sens va la flèche ? Variance, or which way does the arrow go?

Un Cat est un Animal. Mais le sous-typage a une direction dans un conteneur.A Cat is an Animal. But subtyping has a direction inside a container.

Le structurel du Vol 1 a établi que Cat est un sous-type d'Animal. Question du numéro : cette flèche se propage-t-elle aux conteneurs et aux fonctions ? L'intuition dit « oui, dans les deux sens » — et se trompe. Un Cat[] est bien un Animal[] (on peut traiter des chats comme des animaux), mais l'inverse est refusé. La relation n'est pas symétrique : elle a un sens. C'est ça, la variance — et le sens s'inverse là où on s'y attend le moins.Vol 1's structural typing established that Cat is a subtype of Animal. The issue's question: does that arrow propagate to containers and functions? Intuition says 'yes, both ways' — and is wrong. A Cat[] is indeed an Animal[] (you can treat cats as animals), but the reverse is refused. The relation isn't symmetric: it has a direction. That's variance — and the direction flips where you least expect it.

class Animal { name = "" }
class Cat extends Animal { meow() {} }

const cats: Cat[] = [new Cat()];
const animals: Animal[] = cats;     // ✓ ce sens marche…
const backToCats: Cat[] = animals;  // ✗ …mais PAS celui-ci :
//   Type 'Animal[]' is not assignable to type 'Cat[]'  (un Animal n'est pas un Cat)

// Cat <: Animal   (Cat est un sous-type d'Animal — Vol 1)
//   donc  Cat[]    <: Animal[]    ✓  la flèche est PRÉSERVÉE → covariance
//   mais  Animal[] </: Cat[]      ✗  pas l'inverse

const animals: Animal[] = cats;     // ✓ traiter des Cat comme des Animal : toujours sûr

Les paramètres de fonction inversent la flèche. Et c'est exactement ce qui protège.Function parameters flip the arrow. And that's exactly what protects you.

Voici le cœur contre-intuitif du numéro. Les tableaux préservent le sens ; les paramètres de fonction l'inversent. Un handler qui accepte n'importe quel Animal peut remplacer un handler de Cat — parce qu'il accepte les Cat, et davantage. Donc (a: Animal) => void est un sous-type de (a: Cat) => void : la flèche s'est retournée. L'inverse est refusé, et pour une bonne raison : un handler de Cat appelé avec un Dog planterait.Here's the issue's counter-intuitive heart. Arrays preserve the direction; function parameters flip it. A handler that accepts any Animal can replace a Cat handler — because it accepts Cats, and more. So (a: Animal) => void is a subtype of (a: Cat) => void: the arrow turned around. The reverse is refused, for good reason: a Cat handler called with a Dog would crash.

type CatHandler = (a: Cat) => void;

const handleAnimal = (a: Animal) => console.log(a.name);
const h: CatHandler = handleAnimal;   // ✓ un handler d'Animal accepte AUSSI les Cat
//   la flèche s'est inversée : (Animal) => void  <:  (Cat) => void

En position de paramètre, accepter plus (un Animal quelconque) rend la fonction plus substituable, pas moins. Le sous-typage s'inverse : (Animal) => void <: (Cat) => void. C'est la contravariance — l'exact opposé du tableau.In parameter position, accepting more (any Animal) makes the function more substitutable, not less. Subtyping flips: (Animal) => void <: (Cat) => void. That's contravariance — the exact opposite of the array.

La position décide du sens : sortie covariante, entrée contravariante.Position decides the direction: output covariant, input contravariant.

Une seule règle gouverne tout, et elle découle de la substitution. Là où un type est produit — un retour, la valeur d'un Promise, un élément qu'on lit — la flèche est préservée : covariant. Là où un type est consommé — un paramètre — elle s'inverse : contravariant. Et quand T est à la fois lu et écrit (l'élément d'un tableau mutable), il est invariant en théorie : aucun des deux sens n'est sûr. Toute la variance se déduit de « qui fournit, qui reçoit ».One rule governs all, and it follows from substitution. Where a type is produced — a return, a Promise's value, an element you read — the arrow is preserved: covariant. Where a type is consumed — a parameter — it flips: contravariant. And when T is both read and written (a mutable array's element), it's invariant in principle: neither direction is safe. All of variance follows from 'who supplies, who receives'.

// SORTIE / lecture → covariant (la flèche est préservée)
type Producer<T> = () => T;
const pc: Producer<Animal> = (() => new Cat()) as Producer<Cat>;   // ✓ Cat <: Animal

// ENTRÉE / paramètre → contravariant (la flèche s'inverse)
type Consumer<T> = (x: T) => void;
const cc: Consumer<Cat> = ((x: Animal) => {}) as Consumer<Animal>; // ✓ Animal "<:" Cat ici

// La substitution (Liskov), en une phrase :
//   on peut FOURNIR plus (un supertype) là où une entrée est consommée,
//   et RENDRE moins (un sous-type) là où une sortie est produite.
//
//   () => Cat        <:  () => Animal       (retour : covariant)
//   (Animal) => void <:  (Cat) => void      (paramètre : contravariant)

La bivariance des méthodes : le trou que TypeScript tolère sciemment.Method bivariance: the hole TypeScript knowingly tolerates.

strictFunctionTypes a rendu les paramètres de fonction contravariants — sains. Mais il y a une exception assumée : les paramètres écrits en syntaxe de méthode (m(x) au lieu de m: (x) => …) restent bivariants, c'est-à-dire acceptés dans les DEUX sens, y compris l'unsound. C'est un compromis historique, indispensable aux tableaux et aux handlers d'événements, mais c'est un trou réel. La même API change de sûreté selon qu'on l'écrit en méthode ou en propriété-fonction.strictFunctionTypes made function parameters contravariant — sound. But there's an owned exception: parameters written in method syntax (m(x) instead of m: (x) => …) stay bivariant, that is, accepted in BOTH directions, including the unsound one. It's a historical compromise, needed for arrays and event handlers, but it's a real hole. The same API changes safety depending on whether you write it as a method or a function-property.

interface Listener { handle(e: ClickEvent): void }      // ← écrit en MÉTHODE
interface Specific { handle(e: SpecificClick): void }   // exige un événement PLUS spécifique

declare const specific: Specific;
const l: Listener = specific;   // ✓ ACCEPTÉ — et c'est le trou :
l.handle(clickEvent);           //   handle reçoit un ClickEvent sans .detail() → 💥

Écrit en méthode, le paramètre de handle est vérifié bivariamment : le sens contravariant (sûr) et le sens covariant (dangereux) passent tous deux. Le second laisse passer un objet dont handle exige un événement plus spécifique, là où l'appelant, qui ne voit qu'un Listener, lui livrera un ClickEvent nu — sans .detail(). strictFunctionTypes ne couvre pas ce cas.Written as a method, handle's parameter is checked bivariantly: the contravariant (safe) direction and the covariant (dangerous) one both pass. The second lets through an object whose handle demands a more specific event, where the caller — who only sees a Listener — will hand it a bare ClickEvent, with no .detail(). strictFunctionTypes does not cover this case.