Why did TypeScript's designers leave method parameters bivariant instead of checking them contravariantly like other function types, and what unsoundness does that leave in everyday code?

## The rule and the exemption When TypeScript relates two function types, the sound rule for parameters is contravariance: a replacement must accept everything callers were promised they could pass. `strictFunctionTypes` implements that rule — but it deliberately does **not** apply it to members declared with method syntax (or to constructor signatures). Those keep the older **bivariant** comparison, where the relation passes if the parameter types are assignable in either direction. This is not an accident or a bug backlog item. It is documented as an intentional trade. ## Why the exemption had to exist The reason is generic container types. Look at what `Array<T>` actually declares: ```ts interface Array<T> { push(...items: T[]): number; indexOf(searchElement: T, fromIndex?: number): number; includes(searchElement: T, fromIndex?: number): boolean; concat(...items: ConcatArray<T>[]): T[]; } ``` `T` appears in parameter positions all over it. Measure variance structurally and honestly, and `Array<T>` is **invariant** in `T`: neither `Dog[] → Animal[]` nor the reverse is safe. That is the mathematically correct answer, and it is unusable — passing a `Dog[]` to a function that takes `Animal[]` is something almost every codebase does dozens of times, and almost always correctly, because the callee only reads. By exempting methods from the strict rule, TypeScript makes `Array<T>` (and `Map`, `Set`, `Promise`, and every user-written interface built the same way) relate essentially covariantly, so those assignments keep working. The designers accepted a known hole in exchange for not breaking the language's ergonomics. ## The hole, concretely The canonical demonstration is array aliasing: ```ts class Animal { name = "a"; } class Dog extends Animal { fetch() {} } class Cat extends Animal { meow() {} } const dogs: Dog[] = [new Dog()]; const animals: Animal[] = dogs; // allowed animals.push(new Cat()); // type-checks dogs[1].fetch; // undefined at runtime ``` `animals` and `dogs` are the *same object*. The type system permitted the widening and then permitted a write through the widened view, so a `Cat` is now sitting in something typed `Dog[]`. Nothing at runtime notices, because the types are erased; the failure surfaces later, wherever someone calls `.fetch()`. The second shape is callbacks. Any interface that declares a handler with method syntax lets an implementation narrow the parameter: ```ts interface Sink { accept(e: Event): void } const s: Sink = { accept(e: MouseEvent) { console.log(e.clientX); } }; // OK s.accept(new KeyboardEvent("keydown")); // compiles; clientX is undefined ``` Every caller is entitled by the type to pass any `Event`, and the implementation quietly assumed something stronger. ## Diagnosing it in the wild The symptom is a property that is `undefined` (or a method that is not a function) on a value whose type says it should be there, with no assertion or `any` anywhere near the failure. When that happens, look upstream for a widening assignment of a mutable collection, or for an implementation whose parameter type is narrower than the interface it satisfies. Neither shows up as a compile error, so grep-by-symptom is the only route. ## Living with it - **Take `readonly T[]` for parameters you do not mutate.** `readonly Animal[]` has no `push`, so the widening stops being a write hazard. It is still technically unsound in the same way, but the destructive move is gone from the API. - **Declare consumer-supplied callbacks as property function types.** The contravariant check then applies, and a narrower handler is a compile error at the point where it is written. - **Narrow inside the body instead of in the signature.** `if (e instanceof MouseEvent)` is a check that actually exists after erasure; a narrower parameter type is only a promise. - **Do not reach for `strictFunctionTypes: false`.** It removes the sound check from the forms that still have it and buys nothing back. - **Know when to shrug.** Most covariant array passing is read-only and fine. The judgment is about which surfaces are worth hardening, not about eliminating the hole — it cannot be eliminated without breaking the language.