Users of your helper `declare function pipe<A, B>(f: (a: A) => B): (a: A) => B` report that in `pipe(x => x)` the parameter `x` is `unknown`. Why does that happen, and what are your options for fixing it?

## Producers and consumers of a type parameter A type parameter can appear in a signature in two different roles, and inference only cares about one of them. - A **producer** position is one where an argument's type flows *into* the type parameter: `f(value: A)`, `f(items: A[])`, `f(cb: () => A)`. The caller writes a value, the compiler reads a candidate. - A **consumer** position is one where the type parameter flows *out* to describe something: the return type, or the parameters of a callback the caller supplies. `pipe<A, B>(f: (a: A) => B)` puts `A` in a consumer position only. The `a: A` slot exists so the compiler can tell callers what their callback receives; it is not a place where the caller announces a type. `B`, by contrast, has a producer position — the callback's return — which is why `pipe((x: number) => x)` infers `B` correctly once `A` is known. With an empty candidate set, the fallback ladder applies: a declared default, else the constraint, else `unknown`. `A` has neither, so `A` becomes `unknown`, and contextual typing then pushes `unknown` onto the callback's parameter. That is why the reporter sees `x: unknown` and not an implicit-`any` error — nothing is missing an annotation; inference genuinely ran and landed on the fallback. ```ts declare function pipe<A, B>(f: (a: A) => B): (a: A) => B; const p = pipe(x => x); // ^? (a: unknown) => unknown ``` ## Argument order is not the bug The reflex diagnosis — "the callback comes first, so inference has not seen the value yet" — is wrong, and saying so is a good way to show you have actually debugged this. A function expression with un-annotated parameters is **context-sensitive**: its type depends on what is pushed into it. The compiler processes non-context-sensitive arguments first, fixes what it can, and revisits the context-sensitive ones in a later round. So both of these infer correctly: ```ts declare function withInit<T>(cb: (t: T) => void, init: T): void; withInit(t => { t.a; }, { a: 1 }); // fine — T comes from init ``` The problem in `pipe` is not ordering, it is that no argument anywhere produces `A`. ## Four fixes, in the order to consider them **1. Give the type parameter a real inference site.** If the API can take the value, take it — this is the fix that removes the burden from every caller: ```ts declare function apply<A, B>(value: A, f: (a: A) => B): B; apply({ id: "1" }, x => x.id); // string, x fully typed ``` **2. Constrain the type parameter so the fallback is useful.** When the API genuinely cannot see a value, a constraint turns `unknown` into something callers can work with: ```ts declare function pipeC<A extends { id: string }, B>(f: (a: A) => B): (a: A) => B; pipeC(x => x.id); // (a: { id: string }) => string ``` The callback parameter is now contextually typed by the constraint, so `x.id` checks. This is the single highest-leverage change for builder-style APIs whose type parameter cannot be inferred from arguments. **3. Let the caller annotate the callback parameter.** `pipe((x: number) => x)` works, because an annotated parameter is no longer waiting for a context — it supplies the candidate itself, and `A` infers as `number`. Cheap, but it is a tax paid at every call site. **4. Explicit type arguments — with a caveat.** `pipe<number, string>(String)` is legal, but partial application is not: `pipe<number>(x => x)` is rejected with "Expected 2 type arguments, but got 1". You must name every type argument unless the trailing ones declare defaults, which is a good reason to put the parameter callers will want to specify first and give the rest defaults. One more that surprises people: the call's contextual type can also supply the candidate, because an annotated receiving variable is an inference source of lower priority than arguments. ```ts const p: (a: number) => number = pipe(x => x); // A is number ``` That works, but it is a call-site workaround rather than an API fix. ## The judgment an interviewer is listening for All four options compile. Only the first two change the *library*, and that is the distinction to make explicit: option 3 and option 4 push the cost onto every consumer forever, and the cost is paid in annotations that will drift. When you own the signature, the question is not "how do I make this call compile" but "why does this type parameter have no producer, and can the API be reshaped so a natural call needs zero annotations?" Inferability is an API quality attribute — a helper whose callbacks only type correctly when consumers annotate them seeds `unknown` and `any` across every downstream codebase, and none of it is visible at runtime, since the whole type layer is erased.