A generic custom hook ends with `return [value, setValue];` and has no return type annotation. Why does the caller's destructured setValue come out with a union type, and how do you type the hook so the pair destructures correctly?

## Why an array literal is not a pair TypeScript has two related but distinct types for bracketed values. `T[]` is a homogeneous array: any index yields the same element type, and the length is unknown. `[A, B]` is a **tuple**: position 0 has type `A`, position 1 has type `B`, and the length is fixed. When the checker infers a type for an array literal with no contextual type to guide it, it picks the array form and widens the element type to the union of the entries. So this hook: ```typescript type Setter<T> = (next: T) => void; function looseHook<T>(initial: T) { let value = initial; const setValue: Setter<T> = (next) => { value = next; }; return [value, setValue]; // inferred (T | Setter<T>)[] } ``` returns `(T | Setter<T>)[]`. Destructuring reads elements, and every element of that array has the union type, so `const [v, setV] = looseHook(0)` gives both names `number | Setter<number>`. Calling `setV(1)` fails — the checker cannot rule out that it is a `number`. Nothing has gone wrong with generics here; the inference rule is the same for a non-generic function, but generics make it more visible because the union now mentions the type parameter and the error text becomes long. ## The two fixes, and why they differ **Explicit tuple return type** — the one to reach for: ```typescript function pairHook<T>(initial: T): [T, Setter<T>] { let value = initial; const setValue: Setter<T> = (next) => { value = next; }; return [value, setValue]; } const [n, setN] = pairHook(0); // n: number, setN: (next: number) => void ``` The annotation becomes a *contextual type* for the returned literal, so the checker matches it position by position instead of inferring an array. It also documents the hook's contract at the signature, which is what a reader looks at, and it keeps the result mutable. **`as const` on the returned literal**: ```typescript function constHook<T>(initial: T) { let value = initial; const setValue: Setter<T> = (next) => { value = next; }; return [value, setValue] as const; // readonly [T, Setter<T>] } ``` This also produces a positional type, but a `readonly` tuple. For a destructured pair that is harmless and arguably better — nobody should be reassigning the returned array's slots. It only bites when a caller wants to pass the result somewhere that expects a mutable tuple, since `readonly [A, B]` is not assignable to `[A, B]`. Note also that the assertion applies to the whole literal, so it is easy to forget on one of several return statements; the signature annotation cannot be forgotten. ## Naming the positions Tuple members may be labelled, which improves editor hints and error messages without changing the type: ```typescript function useToggle(initial: boolean): [on: boolean, toggle: () => void] { let on = initial; return [on, () => { on = !on; }]; } ``` Labels are documentation only — assignability is unchanged — but for a hook whose two returns are otherwise indistinguishable to a reader, they earn their keep. ## Tuple or object? The tuple exists so that callers can rename freely: two `useState`-style hooks in one function need distinct names, and positional destructuring gives that for nothing. That advantage evaporates past two or three members — a five-element tuple is a memory test, and adding a member in the middle silently reassigns everyone's names. Returning an object is then the better contract: names are explicit, order is irrelevant, and additive changes are backwards-compatible. A good rule is tuple for a pair whose members are obviously ordered (state and setter, value and reset), object for anything richer. Interviewers often push here after the tuple answer, and the expected reasoning is exactly this tradeoff between rename-freedom and self-description. ## The generic angle One detail specific to a generic hook: the type parameter must be inferable from the parameters, because the return type cannot drive inference. `function useThing<T>(initial: T): [T, Setter<T>]` infers `T` from `initial`, which is why `useThing(0)` yields a `number` pair. If the hook takes no argument, the caller has to supply the argument explicitly — `useThing<User | null>()` — or you give the parameter a default. A hook whose parameter is `T | undefined` with a default of `undefined` infers `unknown` when called bare, which is the usual reason a supposedly typed hook comes back useless.