A TypeScript codebase annotates every callback parameter with the built-in `Function` type. What checking does that give up, and what should replace it?

## What `Function` actually is `Function` is a real interface in the standard library, describing the members every function object has: `apply`, `call`, `bind`, `toString`, `length`, `name`, `prototype`. Notice what is *not* there — a call signature describing this particular function's parameters and return type. `Function` is the type of "a function object", not the type of "a function that takes an `Item` and returns a `boolean`". The compiler nevertheless lets you invoke a value typed `Function`, with any arguments at all, and types the result `any`: ```ts function invoke(fn: Function): void { fn(1, 'two', true, {}); // no arity check, no type check const result = fn(); // result: any } ``` ## The three things you lose **Arity.** Passing three arguments to a one-parameter callback compiles. Passing none to a callback that requires two compiles. The most common real-world callback bug — arguments in the wrong order, because a `map` callback is `(value, index)` and someone wrote `(index, value)` — is completely invisible. **Argument and return types.** Nothing relates what you pass to what the callee expects, and the result is `any`. That is the serious one: `any` is not merely "unknown", it is *assignable to everything*, so the unchecked value flows onward and the eventual failure is far from the annotation that caused it. **Kind.** A class is a function object, so a class is assignable to `Function`. The type cannot distinguish a plain callback from a constructor, an async function, or a generator function. ## What to write instead The default answer is simply the signature you mean: ```ts function filterItems(items: Item[], predicate: (item: Item, index: number) => boolean): Item[] { return items.filter(predicate); } ``` Now a wrongly-ordered or wrongly-typed callback is an error at the call site, which is where the mistake was made. When the function is genuinely opaque — you store it, count it, compare it, but never invoke it — say that precisely: ```ts type AnyFunction = (...args: never[]) => unknown; function register(name: string, handler: AnyFunction): void { /* stored, not called */ } register('a', (n: number) => n + 1); // accepted register('b', async (s: string) => s); // accepted ``` Parameters are compared contravariantly, so `never` in the parameter position accepts a function with any parameter types; and because the parameters are `never`, you cannot then call `handler` with anything, which is exactly the discipline you want. The return type `unknown` forces a narrowing step before the result is used, instead of silently becoming assignable to everything. When you *do* need to call it — a wrapper, a memoiser, a timing decorator — capture the shape generically: ```ts function timed<A extends unknown[], R>(fn: (...args: A) => R): (...args: A) => R { return (...args: A): R => { const start = Date.now(); try { return fn(...args); } finally { console.log(Date.now() - start); } }; } ``` The wrapper preserves the original signature end to end, so callers of the wrapped function get the same checking they had before. ## Why `(...args: any[]) => any` is not the fix It is better than `Function` in one respect — it does describe a function rather than a function object — but it hands back `any` on every call and accepts any arguments, so both leaks remain. It is a reasonable last resort inside a declaration you cannot change; it is not a type you should be writing in new application code. ## Migration judgment In an existing codebase, replacing `Function` everywhere at once produces a wall of errors and a temptation to paper over them with assertions. The productive order is: fix the ones whose result is used (those are the `any` leaks that cause incidents), then the ones that are invoked, and finally the store-and-forward ones, which are usually a mechanical swap to the opaque form. Each conversion is a genuine bug hunt, not a formality — mismatched arity is common and has been compiling silently the whole time. ## Interview framing Lead with the mechanism — "`Function` says callable and nothing else, so calls are unchecked and return `any`" — then give the replacements graded by intent: exact signature when you know it, `(...args: never[]) => unknown` when you never call it, a generic capture when you wrap it. That progression is what separates a memorised "don't use `Function`" from real judgment.