In TypeScript, what return type is inferred for a function that always throws — and why does `function fail(m: string) { throw new Error(m); }` infer a different type from `const fail = (m: string) => { throw new Error(m); };`?

## Why a throwing function has a return type at all A return type describes the value the caller receives. If the body always throws — or spins in `while (true)` — the caller never receives anything, because control does not come back. The type that describes "no value ever arrives here" is `never`, the empty type. So `never` is not a marker meaning "returns nothing"; that is `void`, which means "returns, but the result is not meant to be used". `never` means "does not return". ## The asymmetry Give the same body to a declaration and to an arrow function and TypeScript infers two different things: ```ts function failDecl(msg: string) { throw new Error(msg); } // inferred: (msg: string) => void const failExpr = (msg: string) => { throw new Error(msg); }; // inferred: (msg: string) => never function loopDecl() { while (true) {} } // inferred: () => void const loopExpr = () => { while (true) {} }; // inferred: () => never ``` The rule the compiler applies to a function **expression** or **arrow function** is: if it has no return type annotation, has no return statements returning a value, and control-flow analysis shows the end of the body is unreachable, infer `never`. Function **declarations** are excluded from that rule and infer `void` unless you annotate them. The reason is conservatism about a construct that is hoisted and widely referenced. Silently upgrading every throwing declaration to `never` would change the meaning of a lot of existing code, since a `never` return participates in control-flow analysis at every call site. Whatever the history, the practical instruction is simple: **if you want a declaration to return `never`, say so.** ```ts function fail(msg: string): never { throw new Error(msg); } ``` ## What the never return actually buys you The payoff is control-flow analysis. When the checker sees a call to something whose return type is `never`, it knows execution cannot continue past that statement. Two things follow: code after the call is unreachable, and a narrowing established before the call survives afterwards. ```ts function fail(msg: string): never { throw new Error(msg); } function lengthOf(x: string | undefined) { if (x === undefined) fail("missing"); return x.length; // x is string here — the undefined branch could not continue } ``` Without the `never` return, `x` would still be `string | undefined` on the last line and `x.length` would error under `strictNullChecks`. ## The annotation requirement at the call site There is a second, less-known rule, and interviewers who use this question tend to know it. The flow effect only applies when the called function is referenced through a **name whose declaration has an explicit type annotation**. A value that merely *infers* `never` does not get it: ```ts const failNoAnn = (msg: string) => { throw new Error(msg); }; // type is (msg: string) => never, but the const has no annotation function lengthOf(x: string | undefined) { if (x === undefined) failNoAnn("missing"); return x.length; // Error: 'x' is possibly 'undefined' } ``` Annotate the declaration and it works: ```ts const failAnn: (msg: string) => never = (msg) => { throw new Error(msg); }; // now `if (x === undefined) failAnn("missing");` does narrow ``` The same applies to dotted names: `helpers.fail(...)` only ends the flow when `helpers` itself is declared with an explicit type. This is the same restriction that governs assertion functions, and it exists so the checker does not have to infer types it is in the middle of using to compute flow. ## Practical guidance - Write `: never` explicitly on any throw-helper you intend other code to rely on — `fail`, `unreachable`, `notImplemented`, a `panic` wrapper. - Annotate the *variable* too if the helper is a `const` arrow, not just the arrow's return. - Remember `never` is a subtype of everything, so a never-returning call is legal in an expression position: `const value = cache.get(k) ?? fail("missing")` type-checks, and the result type is just the non-never side. - Do not reach for `never` on a function that merely returns nothing useful. If it can complete, its return type is `void`. ## The runtime caveat All of this is erased. `: never` compiles to nothing; the only thing that actually stops execution is the `throw` or the infinite loop in the body. If a helper is annotated `never` but a refactor makes some path return normally, the compiler keeps trusting the annotation — a stale `never` silently teaches the checker something false about every call site. Keep the annotation and the body honest together.