In TypeScript with strict enabled, given `class Dog extends Animal` and `interface Cell<T> { value: T; set: (next: T) => void }`, is `Cell<Dog>` assignable to `Cell<Animal>`, is `Cell<Animal>` assignable to `Cell<Dog>`, or neither — and why?

## The short answer, then the reason Neither assignment compiles. `Cell<T>` is **invariant** in `T`, meaning the only `Cell` assignable to `Cell<Animal>` is another `Cell<Animal>` (or a type mutually assignable with it). ## Two members pulling in opposite directions Variance is decided by where the type parameter appears, and `Cell` puts it in both kinds of place at once: ```ts interface Cell<T> { value: T; // output position -> wants covariance set: (next: T) => void; // input position -> wants contravariance } ``` Assignability between two object types is checked member by member, and **every** member must succeed. Test `Cell<Dog>` against `Cell<Animal>`: - `value`: source has `Dog`, target requires `Animal`. `Dog` is assignable to `Animal`, so this member passes. - `set`: source has `(next: Dog) => void`, target requires `(next: Animal) => void`. Parameter positions are checked contravariantly under `strict`, so this passes only if `Animal` is assignable to `Dog` — it is not. This member fails. One failing member is enough, so the whole assignment is rejected. Now test the other direction, `Cell<Animal>` against `Cell<Dog>`: - `value`: source has `Animal`, target requires `Dog`. `Animal` is not assignable to `Dog`. Fails immediately. Both directions fail, each for a different member. That is the definition of invariance: the covariant requirement and the contravariant requirement can only both hold when the type arguments are the same. ## Why the rule is protecting you Invariance on a mutable container is not bureaucracy — it is the single most important soundness rule in the whole area. Imagine the first assignment were permitted: ```ts declare const dogCell: Cell<Dog>; const asAnimal: Cell<Animal> = dogCell; // suppose this were allowed asAnimal.set(new Cat()); // perfectly legal for a Cell<Animal> dogCell.value.bark(); // typed Dog, actually a Cat ``` Every individual step is legitimate under its own type. The alias created a hole through which a `Cat` entered a container the original owner still believes holds only dogs, and the failure surfaces far away, at a call that the checker had already blessed. Because TypeScript's types are erased, nothing at runtime will catch it — no cast happens, no check runs, the property access simply finds no `bark` method and throws. A mutable container is simultaneously a producer and a consumer, and there is no way to substitute a different element type that is safe for both roles at once. Invariance is the only correct answer. ## Recognising it in real code The pattern to watch for is a type that was covariant until somebody added a writing member. A `Repository<T>` with only `findAll(): T[]` is covariant and flows freely; the day a `save: (item: T) => void` lands on it, every call site that relied on passing `Repository<Dog>` where `Repository<Animal>` was wanted starts failing, and the diff that broke them touched neither call site. Recognising the cause as a variance change — rather than a mysterious assignability regression — is most of the value of understanding this topic. The same shape appears in setters and getters, in event buses that both publish and subscribe, in caches, and in any options object holding both a default value of type `T` and a callback taking a `T`. ## What to do about it The principled fix is to stop requiring the whole invariant type where only half of it is used. If a function only reads, ask for a type whose parameter appears only in output positions; if it only writes, ask for one whose parameter appears only in input positions. The full read-write type can extend both, so existing values still satisfy every API, and each caller gets whichever variance its own usage actually supports. The unprincipled fixes are worth naming so you can reject them in review. An `as` assertion silences the error and reintroduces exactly the cat-in-the-dog-cell hazard, with no runtime check anywhere. Widening the container to `Cell<any>` does the same thing more quietly. And an explicit variance annotation cannot help either: annotations state the variance a type already has and are verified against its members — they cannot grant a mutable container a variance it does not possess. One related nuance is deliberately out of scope here: writing the consumer as a method shorthand rather than a function-typed property changes how its parameters are compared, which is a separate topic in its own right.