In TypeScript, why does `[1, 2, 3].forEach(n => results.push(n))` type-check, even though Array.prototype.push returns a number and forEach's callback is declared to return void?

## What void means in return position `void` is not "undefined". It is TypeScript's way of writing "this function returns something you must not look at". That reading is what makes the assignability rule sensible rather than a loophole. The rule: **a function type whose return type is `void` will accept a function that returns any type at all.** So all of these are legal: ```ts type Handler = () => void; const a: Handler = () => {}; // returns undefined const b: Handler = () => 42; // returns number — still fine const c: Handler = async () => {}; // returns Promise<void> — also fine ``` ## Why the rule has to exist Without it, the most ordinary line of callback code would fail: ```ts const results: number[] = []; [1, 2, 3].forEach(n => results.push(n)); ``` `Array.prototype.forEach` declares its callback as `(value: T, index: number, array: T[]) => void`. `Array.prototype.push` returns the array's new `length`, a `number`. The concise arrow body `results.push(n)` is an implicit return, so the arrow's type is `(n: number) => number`. If `void` required the source function to return nothing, you would have to write `n => { results.push(n); }` with braces everywhere, and every existing callback that happened to return a value would break. The deeper justification is that ignoring a returned value is always safe. A caller that discards the result cannot be broken by the result having a type — nothing downstream depends on it. This is the same reasoning that makes it safe for a subtype to return *more* than the supertype promised. ## The rule is about assignment, not declaration This is where candidates usually trip. The permissiveness only applies when you assign a function *to* a void-returning function type. When you declare the return type on the function itself, you are the one making the promise, and TypeScript holds you to it: ```ts function f(): void { return 42; // Error: Type 'number' is not assignable to type 'void'. } ``` So `void` behaves one way as a *target* of assignment and another as your own declared contract. Both follow from the same idea — the target says "I will ignore your result", while the declaration says "I produce no useful result". ## The value really is invisible The returned value still exists at runtime; the type system just refuses to hand it to you. ```ts const f: () => void = () => 42; const r = f(); // r: void r.toFixed(2); // Error: Property 'toFixed' does not exist on type 'void'. const n: number = r; // Error: Type 'void' is not assignable to type 'number'. ``` This is exactly what you want. The contract said the result is meaningless; the type system enforces that nobody quietly starts depending on it. If a value at that position *is* meaningful, the callback type is wrong and should say `=> number`. ## void versus undefined as a return type They are different types and the difference is precisely this rule. ```ts type ReturnsVoid = () => void; type ReturnsUndefined = () => undefined; const ok: ReturnsVoid = () => 42; // fine const bad: ReturnsUndefined = () => 42; // Error: number is not assignable to undefined ``` `undefined` is an ordinary type with exactly one value, so it demands that value. Use it when the caller genuinely reads the result and `undefined` is a meaningful outcome — an unsuccessful lookup, say. Use `void` when the result is to be thrown away. In practice, callback and handler parameter types should almost always say `void`, precisely so implementers are not forced to add braces. ## Where the rule bites Because `Promise<void>` is a type like any other, an `async` callback slots into a `() => void` parameter with no complaint. The type system is behaving correctly — the caller did say it would ignore the result — but the ignored result is a promise, and ignoring a promise is rarely what the author wanted. That is the practical cost of an otherwise well-motivated rule, and it is why callback types that will be awaited should say so, for example `() => void | Promise<void>`. One more consequence worth knowing: `void` in a *parameter* or variable position is a different thing entirely. `let v: void` can hold only `undefined` (and `null` when `strictNullChecks` is off), which is why `void` outside return position is almost never useful.