You pass a generic component `function List<T>(props: ListProps<T>): string` to a helper declared as `function wrap<P>(component: (props: P) => string): (props: P) => string`. The wrapped result no longer infers the item type at each usage. Which TypeScript rule causes that, and what is the standard fix?

## Generic in, concrete out A generic function's type is a signature with unfilled slots: `<T>(props: ListProps<T>) => string`. A parameter typed `(props: P) => string` — where `P` is the *helper's* own parameter, fixed at that call — is a signature with no slots. When you pass the first where the second is expected, TypeScript does not carry the polymorphism through; it **instantiates** the argument's type parameters so that the result matches the target. That is the whole rule, and it explains the symptom: after `wrap(List)`, there is no `T` left to infer, so every usage of the wrapped component shares one element type. What does `T` become? Inference for it runs against the target signature, which mentions `T` nowhere useful, so it falls back — to the constraint if there is one, otherwise `unknown`. `P` then infers as `ListProps<unknown>`, and callers see errors that look nothing like the real cause: an object of `User` values not assignable to `readonly unknown[]`'s neighbours, a render callback whose parameter is `unknown`. TypeScript can preserve genericity, but only positionally: assigning `<T>(x: T) => T` to a variable declared `<U>(x: U) => U` keeps the signature generic, because the target has a slot to keep it in. Inferring *into* a type parameter, as `wrap` does, is the case that collapses. The general feature that would make `wrap` work — a parameter that ranges over generic signatures — is higher-rank polymorphism, and TypeScript's inference does not provide it. ## The fix everyone uses ```typescript interface ListProps<T> { items: readonly T[]; renderItem: (item: T) => string; } declare function List<T>(props: ListProps<T>): string; declare function wrap<P>(component: (props: P) => string): (props: P) => string; // collapsed: WrongList is (props: ListProps<unknown>) => string const WrongList = wrap(List); // restored: the assertion re-states the generic signature const WrappedList = wrap(List) as typeof List; ``` `typeof List` is the generic signature verbatim, so the asserted constant behaves at usage sites exactly like the original: `T` is inferred per call again. This is the identical idiom applied to React's `memo`, which is declared with its own props type parameter and therefore hits precisely this rule — `const MemoList = memo(List) as typeof List;` is the line you will find in real codebases and the one an interviewer is fishing for. Be honest about what the assertion costs. It is unchecked: the compiler now believes the wrapped value has `List`'s type on your say-so, and if the helper's real return type differs in any way that matters — extra members you intended to use, a different call shape — you have hidden that. It also throws away anything the wrapper's return type added beyond the call signature. Keep the assertion adjacent to the wrap call so a reader sees both, and never widen it into a reusable helper that asserts arbitrary wrappers. ## The alternative: keep the parameter in scope If you control the call site, you can avoid the assertion by wrapping *inside* a generic function, where `T` is still bound: ```typescript function makeWrappedList<T>(): (props: ListProps<T>) => string { return wrap<ListProps<T>>(List); } ``` This is honest — no assertion — but it moves the instantiation to whoever calls the factory, which for a memoised component defeats the purpose, since each call produces a fresh wrapped value. That tradeoff is the substance of a senior answer: the assertion buys per-usage inference at the cost of one unchecked line, and the factory buys soundness at the cost of identity. ## Where else the collapse shows up The same rule fires whenever a generic function meets a non-generic function-typed slot: storing a generic function in a registry typed `Record<string, (x: SomeProps) => string>`, passing one as a callback whose parameter type is already fixed, or spreading it through a decorator-shaped helper. The tell is always identical — the type parameter silently becomes `unknown` and errors surface at the *callers* rather than at the assignment. When you see `unknown` where you expected an inferred type, look for the last place the value passed through a non-generic signature. ## Answering it well Name the rule (a generic signature is instantiated when the target is not generic), name the resulting instantiation (`unknown` or the constraint), give the assertion idiom, and state its risk. Candidates who only recite `as typeof List` without the rule usually cannot explain why it works, and the follow-up about what `T` became exposes that immediately.