In TypeScript, what do `ReturnType` and `Parameters` give you when applied to an overloaded function and to a generic function, and why does that break a wrapper built on them?

## Both utilities read one signature `ReturnType<T>` and `Parameters<T>` are conditional types that match `T` against a single function shape. A function *type* in TypeScript can carry several call signatures, but the extraction still resolves to one. That is the root of both failures below. ## Overloads: the last signature wins ```ts declare function ov(x: string): number; declare function ov(x: number): boolean; type R = ReturnType<typeof ov>; // boolean type P = Parameters<typeof ov>; // [x: number] ``` Inference against a type with multiple call signatures picks the **last** one. Nothing warns you; the earlier overloads are simply not represented. This is quietly destructive in a wrapper: ```ts function logged(...args: Parameters<typeof ov>): ReturnType<typeof ov> { return ov(...args); } logged("hello"); // Error — the wrapper only accepts a number now ``` The wrapper compiles, looks correct in review, and rejects a call the original function accepted. The remedy is to declare the overloads on the wrapper too, or to type the wrapper against the underlying implementation shape rather than derive it. There is no built-in utility that returns a union of all overload signatures. ## Generics: the parameters are already gone ```ts declare function identity<T>(x: T): T; type R1 = ReturnType<typeof identity>; // unknown declare function firstChar<T extends string>(x: T): T; type R2 = ReturnType<typeof firstChar>; // string ``` When the checker extracts from a generic signature, it instantiates the type parameters first — an unconstrained parameter becomes `unknown`, a constrained one collapses to its constraint. The extraction then reports that instantiated result. This is not a bug; there is genuinely no single return type for a generic function, because the answer depends on the call. But the consequence is that deriving destroys exactly the property that made the function generic: the *relationship* between what goes in and what comes out. ```ts // Wrong: every call now returns unknown. function loggedIdentity( ...args: Parameters<typeof identity> ): ReturnType<typeof identity> { return identity(...args); } // Right: the wrapper carries its own type parameter. function loggedIdentity2<T>(x: T): T { console.log(x); return identity(x); } ``` The generic wrapper is more typing and it is the only version that preserves the caller's type. ## How to spot it before it ships The symptom in review is a wrapper that type-checks while its call sites start failing, or a derived alias that hovers as `unknown` where you expected a concrete shape. Two habits catch it: - Before deriving from a function, look at whether the declaration has more than one signature or any type parameters. If it does, deriving is the wrong tool. - Assert the derived type rather than trusting the hover. A line such as `const _check: ReturnType<typeof ov> = someNumber;` fails loudly when the extraction picked a signature you did not expect. ## A related trap: the implementation signature An overloaded function's *implementation* signature — the wide one written last, often with `any` or union parameters — is not visible to callers at all. Candidates sometimes assume `Parameters` will surface it since it is physically last in the file. It does not: only the declared overloads participate, and the implementation signature is deliberately excluded from the function's external type. So the choice is between the declared overloads, and the last of those is the one you get. ## The judgment to demonstrate The senior answer is not "here is the workaround" but "here is when derivation is the wrong shape of tool". `ReturnType` and `Parameters` are for transparently forwarding a **single concrete signature**. The moment the function's contract is polymorphic — overloads, generics, conditional return types — the wrapper needs its own polymorphic declaration, because a derived alias can only ever record one instantiation of a contract that has many. Reaching for a cleverer type-level workaround here usually produces something slower to check and harder for the next reader than simply writing the wrapper's signature out.