In TypeScript, the function `function add(a, b) { return a + b; }` is rejected under the `noImplicitAny` compiler option, yet the same function needs no return type annotation at all. Why does the compiler treat parameters and return types so differently?

## The one rule behind the asymmetry TypeScript infers what it can derive from the source in front of it and refuses to guess at anything else. A function body is source it can read; the set of future call sites is not. That single fact explains the whole asymmetry between parameters and return types. ## Why the return type comes for free Give the parameters types and the body becomes fully checkable: ```ts function add(a: number, b: number) { return a + b; } ``` The compiler types `a + b` as `number`, collects the types of every `return` expression, unions them, and uses the result as the function's return type. `add` has type `(a: number, b: number) => number` even though nobody wrote `: number`. With several returns it unions them: ```ts function find(id: string, table: Record<string, string>) { if (id in table) return table[id]; // string return null; // null } // inferred: (id: string, table: Record<string, string>) => string | null ``` If a function never returns a value, the inferred return type is `void`; if every path throws or loops forever, it can be `never`. ## Why parameters cannot be inferred There is no equivalent evidence for an input. A function declaration is written once and called from anywhere — possibly from files that do not exist yet, possibly from a different package. Inferring `a` from the call sites would mean the meaning of a function depended on who happened to call it, and adding a new caller could retroactively change the type of an existing one. TypeScript does not do that. It also, importantly, does **not** infer parameter types from *usage inside the body*. Writing `a.toUpperCase()` does not make `a` a `string`: ```ts function shout(a) { // error under noImplicitAny: 'a' implicitly has an 'any' type return a.toUpperCase(); } ``` Some other languages do this kind of usage-based inference; TypeScript deliberately does not, because it would make the parameter type depend on the implementation rather than on the declared contract. ## What implicit `any` actually costs With `noImplicitAny` off, the code above compiles, `a` is `any`, and the damage spreads. `a.toUpperCase()` is `any`, so the inferred return type is `any`, so every call expression is `any`, so every downstream assignment from that call is unchecked. One un-annotated parameter can silently disable checking across a whole call chain. That is why `noImplicitAny` exists and why it is part of the `strict` family: it turns a silent hole into a visible one at the exact place the information is missing. Note the flag's precise name and scope — it complains about *implicit* `any`. An explicit `a: any` is still legal; the flag only objects when the compiler had to fall back to `any` on its own. ## Where parameters do get types without annotations There is one genuine exception, and it is not a hole in the rule — it is the same rule applied in the other direction. When a function *expression* is written in a position that already has an expected type, the expected type supplies the parameter types: ```ts const lengths = ["a", "bb"].map((s) => s.length); // s: string, no annotation needed ``` Here the evidence exists in the source: the declared signature of the callback parameter. That mechanism is contextual typing. It works for function expressions and arrow functions, never for a standalone function declaration, which by construction has no surrounding expected type. ## The habit to take away Annotate parameters; leave the return type inferred by default. The parameter annotations are the ones carrying real information — they are the function's contract with its callers and the compiler cannot recover them. The return annotation mostly restates what the body already proves, which is why it is optional and why it is worth adding only for specific reasons, such as pinning a public contract or breaking the inference cycle in a recursive function. ## Erasure, as always None of this survives compilation. `a: number` is checked at build time and stripped from the emitted JavaScript; no argument is validated at runtime. Annotating a parameter tells the compiler what you promise callers will pass, not what the function will verify.