In TypeScript, `['a', 'bb'].map(s => s.length)` compiles with no annotation on `s`, but `const len = (s) => s.length;` is an error under `noImplicitAny`. What is the difference between the two positions?

## Two directions in which types travel Most of the time you think of types flowing *outward*: you annotate the inputs, the compiler works out the result. Contextual typing is the inward flow. When the compiler already knows what type is expected at a position, it pushes that type down into the expression written there — and for a function expression, that means handing types to the parameters. ## What supplies the context The callback case is the one everybody meets first. In the standard library, `map` is declared roughly as: ```ts map<U>(callbackfn: (value: T, index: number, array: T[]) => U, thisArg?: any): U[]; ``` On `['a', 'bb']`, `T` is `string`. When you write `.map(s => s.length)`, the compiler already knows the argument's expected type is `(value: string, index: number, array: string[]) => U`, so it matches your parameters against that signature **by position** and types `s` as `string`. Your name for the parameter is irrelevant; only its position matters. You may also declare fewer parameters than the signature offers — `s => ...` ignoring `index` and `array` is fine — and the ones you do declare are typed from the front. Callback arguments are not the only source of context. All of these supply one: ```ts type Compare = (a: number, b: number) => number; const byValue: Compare = (a, b) => a - b; // from the variable's annotation const handlers: Record<string, (n: number) => void> = { log: (n) => console.log(n), // from the property type }; function pick(cmp: Compare) {} pick((a, b) => b - a); // from the parameter type ``` A type assertion, a `return` inside a function with an annotated return type, and the right-hand side of an assignment to an already-typed variable all supply context too. ## Why the standalone arrow gets nothing `const len = (s) => s.length;` has no annotation on `len`, so there is no expected type to push inward. The arrow is the source of truth, not the consumer of one. `s` therefore falls back to implicit `any`, `noImplicitAny` errors, and — worth noticing — the inferred type of `len` becomes `(s: any) => any`, so the hole would propagate to every caller if the flag were off. Two fixes, and they are genuinely different in intent: ```ts const len = (s: string) => s.length; // annotate the parameter const len2: (s: string) => number = (s) => s.length; // annotate the variable, reintroducing context ``` The first states the contract inline. The second is what you want when a named function type already exists: write it once on the variable and every parameter, plus the return type, is checked against it. ## Declarations never get context Contextual typing applies to function *expressions* and arrow functions. A function declaration is a statement, not an expression sitting in a typed position, so it never receives context — which is why the rule "annotate the parameters of your declarations" holds without exception, while callbacks routinely need no annotations at all. ## Where the context runs out Contextual typing is a real mechanism with real edges, and the failures look confusing until you know the cause: - **Extract the callback into a variable and the context disappears.** `const cb = (s) => s.length;` then `arr.map(cb)` — the arrow is now checked in isolation, with no expected type, so `s` is an implicit any. Annotate it, or type the variable. - **Overloaded targets.** When the parameter's declared type is an overloaded function type, contextual typing does not merge the overloads, and parameters can come out as something you did not expect. - **Union-typed positions.** If the expected type is a union of function types, the compiler may fail to pick one and leave the parameters implicitly any. - **Callbacks nested in an object literal passed to a generic function.** Inference for the type parameter may not have settled when the callback is checked, so the callback loses the context you expected it to have. In all of these the remedy is the same: put the annotation back, either on the parameter or on the variable holding the function. ## Why this is worth understanding, not just memorising The practical payoff is knowing which annotations are load-bearing. Annotating callback parameters that the context already types is noise, and worse, it can be silently *wrong* in a way an inferred parameter cannot — you can write `(s: string | undefined) => ...` where the context guarantees `string`, and that widened type sticks for the whole body. Leave contextual positions bare, annotate everything that has no context, and a codebase ends up with annotations exactly where information is actually being supplied rather than restated.