A TypeScript codebase declares `type Logger = (string) => void;` and, oddly, values of that type accept an argument of any type at all. What does that type expression actually mean, and how should it be written?

## The syntax, precisely A function type expression is written like a parameter list followed by an arrow and a return type: ```ts type Handler = (event: string, retries: number) => void; ``` Every parameter needs **both** a name and a type annotation. That requirement is what produces the trap. `(string) => void` is syntactically valid — it is a parameter list containing one parameter whose *name* is `string`: ```ts type Bad = (string) => void; // one parameter named "string", type implicitly any type Good = (value: string) => void; // one parameter of type string ``` The distinction is invisible if you read it as "a function taking a string", which is exactly how the same shape reads in several other languages. TypeScript needs the names because the same grammar supports optional parameters, rest parameters and destructuring, all of which attach to a named binding. ## Why it is silent, and when it is not `Bad`'s parameter has no annotation, so it is an implicit `any`. Under `noImplicitAny` — part of `strict` — the compiler reports it at the type declaration itself, which is why strict projects catch this immediately. With the flag off, nothing is reported: the type compiles, every call passes type checking whatever you hand it, and the checker silently stops helping at that boundary. This is one of the standard arguments for turning `noImplicitAny` on before a codebase accumulates type aliases like this one. ## Parameter names are labels Once the type is written correctly, the names in it carry no checking weight. Assignability between function types compares parameters **by position**: ```ts type Handler = (event: string, retries: number) => void; const onFail: Handler = (message, attempts) => { // message: string, attempts: number — from the position, not from the name }; ``` The implementation may rename freely, and it may declare **fewer** parameters than the type promises — a function that ignores trailing arguments is safe wherever more are supplied. The names still matter to humans: they appear in editor hints and signature help, so `(event: string, retries: number)` is materially better documentation than `(a: string, b: number)`. Because the type supplies parameter types contextually, repeating the annotations in the implementation is redundant, and a re-annotation that is wider than the contract quietly weakens the body. ## Where else the same shape appears The arrow form is one of several ways to say "callable". Written as a member inside an object type, the same idea uses a colon: ```ts type Fn = (n: number) => string; // function type expression type Obj = { format(n: number): string }; // method member inside an object type ``` Mixing the two up produces confusing errors — `type Fn = (n: number): string;` does not parse. Remember: a standalone function type uses `=>`; a member inside an object type uses `:`. A function type expression can be used anywhere a type is expected, not only in an alias: ```ts function retry(op: () => Promise<void>, onError: (e: unknown) => void) { /* ... */ } ``` That inline form is idiomatic for a one-off callback; give it a name with `type` when the same shape appears in several places, or when the name itself carries meaning (`Reducer`, `Validator`, `Middleware`). ## Small details worth knowing - The return type is mandatory in a function type expression; there is no body to infer from, so you must write `=> void`, `=> string`, and so on. - A parameterless function type is `() => T`; the empty parameter list is required. - Because parameter names are just bindings, optional (`?`) and rest parameters are written inside the type exactly as in a real signature. - The whole construct is erased. A `Logger` value is an ordinary JavaScript function at runtime with no argument checking whatsoever; the type only constrains what the compiler will let you pass. ## The takeaway Read a function type as a parameter list, not as a tuple of types. Every parameter position needs `name: Type`. A bare identifier there is a name, and a name without an annotation is an `any` — the exact hole the type alias was supposed to close.