In TypeScript, for `declare function make<T>(): T`, what type does `T` get at `const x = make()`, and what changes if the signature is `declare function makeStr<T extends string>(): T`?

## An empty candidate set Inference works by matching arguments against parameter types and collecting **candidates** for each type parameter. Every parameter position that mentions the type parameter is an inference site. `declare function make<T>(): T` has no parameters at all, so there is no inference site, and the candidate set for `T` comes back empty. The return position does not help: it *consumes* `T` to describe the result, it does not supply a type. The compiler still has to produce something — a call expression must have a type — so it falls back. ## The fallback ladder In order: 1. **A declared default.** `function make<T = string>(): T` uses `string` when inference finds nothing. 2. **The constraint.** `<T extends string>` falls back to `string`; `<T extends { id: number }>` falls back to `{ id: number }`. 3. **`unknown`.** With neither a default nor a constraint, this is where an uninferred type parameter lands. ```ts declare function make<T>(): T; declare function makeStr<T extends string>(): T; declare function makeRow<T extends { id: number }>(): T; const a = make(); // unknown const b = makeStr(); // string const c = makeRow(); // { id: number } ``` The constraint doing double duty is worth internalising: a constraint is normally read as a *restriction* on what callers may pass, but it is also the compiler's best guess when callers supply nothing. Adding a constraint to a type parameter therefore improves the failure mode, not just the success case — an uninferred `T` becomes a usable type instead of `unknown`. ## Why `unknown` and not `any` `unknown` is the top type with no capabilities: you may hold it, but you cannot call it, read a property off it, or assign it to anything narrower without narrowing or asserting first. That means an inference failure is *loud* at the first real use. `any` would be silent, disabling checking on everything downstream and letting a genuine modelling gap propagate through a codebase. The fallback is deliberately the safe end of that pair. ## The caller's escape hatch Explicit type arguments override the fallback entirely: ```ts const when = make<Date>(); // Date ``` Supplying them is all-or-nothing: you must provide a type argument for every type parameter unless the trailing ones have defaults. A two-parameter generic called with one type argument is rejected with "Expected 2 type arguments, but got 1", so declaring a default on the second parameter is what makes a partial `f<Something>()` call legal. ## Where this shows up in real code The pattern appears whenever a function produces a value whose shape it cannot know: a parse or deserialise helper, a fetch wrapper, a mock or stub factory, a storage getter keyed by string. All of them have a return-only type parameter, and all of them therefore return `unknown` unless the caller names the type. And that is the honest reading of such a signature: **the type argument is an assertion by the caller, not a check by the function.** Types are erased, so a `make<Config>()` performs no validation whatsoever — the value that comes back is whatever the implementation produced, and the compiler has simply been told to believe it is a `Config`. Falling back to `unknown` when the caller says nothing is the compiler's way of refusing to make that assertion on your behalf. ## Two adjacent cases not to confuse An empty candidate set is not the same as a *conflicting* one: when arguments supply candidates that disagree, you get an assignability error, not a fallback. And an uninferred type parameter is not the same as an implicit `any` parameter: the first is a generic landing on `unknown` and is perfectly legal under `strict`, the second is a missing annotation that `noImplicitAny` reports. Being able to tell those three failure shapes apart on sight — empty, conflicting, un-annotated — is most of what this topic is testing.