In TypeScript, when the same `infer U` name appears at two positions of one conditional type's `extends` clause, when do you get a union of the candidates and when do you get an intersection?

## Two candidates, one variable A single `extends` clause may mention the same inference name more than once: ```ts type Both<T> = T extends { a: infer U; b: infer U } ? U : never; ``` When the compiler matches `{ a: string; b: number }` against that pattern, it collects *two* candidates for `U`. It then has to produce one type, and the rule it uses depends on where the candidates were found. ## The rule **Covariant positions produce a union.** A covariant position is one where a more specific type is safely usable in place of a wider one: object property types, array element types, function return types. Combining candidates there with a union is safe, because a value in that position is one or the other. ```ts type Co<T> = T extends { a: infer U; b: infer U } ? U : never; type X = Co<{ a: string; b: number }>; // string | number ``` **Contravariant positions produce an intersection.** A parameter type is contravariant: a function that accepts a *wider* type can stand in for one that accepts a narrower type. If one candidate came from a parameter accepting `string` and another from a parameter accepting `number`, the only type usable in *both* places is one that is simultaneously both. ```ts type Contra<T> = T extends { f: (x: infer U) => void; g: (x: infer U) => void; } ? U : never; type Y = Contra<{ f: (x: string) => void; g: (x: number) => void }>; // string & number — nothing satisfies it ``` ## Why the diagnosis matters The symptom in a real codebase is a helper that "works" until someone passes two handlers with different payloads, and then every call site fails with an error mentioning a type nothing can produce. Engineers who do not know this rule tend to blame the call site and start adding assertions, which buries the problem instead of fixing it. Recognising an intersection of unrelated primitives as *the signature of a reused inference name in parameter position* is the whole skill here. The same rule is what powers the well-known union-to-intersection trick, where a helper deliberately places `infer U` in a parameter position precisely to obtain an intersection. So the behaviour is exploited as often as it is stumbled over. ## Fixing it Use distinct names and combine them yourself — explicitly, and visibly at the point of the decision: ```ts type Payload<T> = T extends { f: (x: infer A) => void; g: (x: infer B) => void; } ? A | B : never; ``` Now the union is your choice rather than an emergent property of variance, and a future reader can see it. If you genuinely want only one of the positions, infer only that one and leave the other slot as `any` or `never` in the pattern. A second option is to restructure the input type so the shared piece is named once — for example a single generic parameter on the source interface, which the pattern can then capture in one place. That is usually the better fix when you own the type being matched: it removes the ambiguity at the source instead of resolving it at the extraction site. ## Where the boundary of this rule is This is purely about how *one* conditional combines *multiple candidates for one name*. It is not about how a conditional behaves when the type being checked is itself a union — that is a different mechanism with different rules. Keeping the two apart is worth doing deliberately in an interview, because they produce superficially similar unions from very different causes. And, as always in this layer, nothing here exists at runtime: the compiler resolves the candidates during checking and emits no trace of the reasoning.