What do the `in`, `out` and `in out` variance annotations on a TypeScript generic type parameter do, and why add them when the compiler already works variance out from usage?

## What the syntax says Since TypeScript 4.7 a type parameter of a generic interface or type alias may carry a variance modifier: ```ts interface Getter<out T> { get: () => T } interface Setter<in T> { set: (value: T) => void } interface Ref<in out T> { get: () => T; set: (value: T) => void } ``` - `out T` — **covariant**. `T` may appear only in output positions, and `Getter<Dog>` is assignable to `Getter<Animal>`. - `in T` — **contravariant**. `T` may appear only in input positions, and `Setter<Animal>` is assignable to `Setter<Dog>`. - `in out T` — **invariant**. `T` appears in both kinds of position, and only the same type argument is assignable. The keywords match the producer/consumer intuition directly: a covariant parameter is one that only comes *out* of the type, a contravariant one only goes *in*. ## They describe, they do not decide This is the point interviewers are usually probing. TypeScript's default behaviour is to measure variance from usage — the annotation is not what makes a type covariant. Write the annotation and the compiler checks it against the members, reporting an error on the annotation when the two disagree: ```ts interface Wrong<out T> { set: (value: T) => void } // error: T is used contravariantly ``` So an annotation cannot rescue an invariant type. If your container both reads and writes `T`, marking it `out` does not grant it covariance; it produces a compile error. The only way to get covariant assignability is to change the members so the parameter really is only produced. ## Why they exist at all There are two honest reasons to reach for them. **Intent.** In a large public type, `out T` states a contract to future maintainers: this parameter is produced, never consumed. If someone later adds a member that accepts a `T`, the annotation turns what would have been a silent variance change — and a wave of assignability errors at distant call sites — into an immediate, local compile error on the type they just edited. That is a genuinely valuable guard rail on a widely depended-on type. **Checker performance.** To decide whether two instantiations of a generic relate, the checker normally compares them structurally, member by member, instantiated with the respective type arguments. For a deeply nested or recursive generic — the kind that shows up in type-level libraries, builder chains, and heavily generic component props — that comparison can be very expensive, and it happens over and over during a build. A declared variance lets the checker take a shortcut: if the parameter is known covariant, relating `C<A>` to `C<B>` reduces to relating `A` to `B`, with no member walk at all. ## The cost of the shortcut That shortcut is exactly why these annotations should not be sprinkled everywhere. The structural comparison and the variance-based comparison are not always identical in their verdicts: structural comparison sometimes succeeds in cases the coarser variance rule rejects. When you declare the variance, you are telling the checker it may rely on the fast path, so an assignment that used to be accepted by the member-by-member fallback can begin to report an error. The change is correct in the sense that it follows the declared variance, but it is a behaviour change in your codebase, not merely a comment. The practical rule: leave variance inferred by default; add annotations to a small number of hot, deeply generic types where you have measured a type-checking cost, or to a stable public type whose variance you want frozen as part of its contract. ## What they are not Three things worth stating plainly, because each is a common wrong answer: - They emit nothing. Like every other part of the type layer, variance annotations are erased; the JavaScript output is byte-identical with or without them. - They are not the same feature as declaration-site variance being *required*. In languages where variance must be declared, an unannotated parameter is invariant by default. In TypeScript the unannotated case is fully inferred, so annotations are additive. - They do not affect inference of the type argument. `out` does not mean "infer this from the return type", and `in` does not steer argument inference; controlling inference is a different mechanism entirely. ## How to talk about it A strong answer names the three forms, says explicitly that TypeScript verifies rather than obeys them, and gives the two motivations — intent and check performance — before conceding that the fast path can change results in edge cases. A weak answer describes them as the way you make a generic covariant, which inverts the entire relationship between the annotation and the type.