In TypeScript, what rules govern default type parameters — where a default may appear in the list, what type it may reference, and how it interacts with an `extends` constraint on the same parameter?

## Position: defaults live at the tail A type parameter with a default is optional, and an optional parameter cannot be followed by a required one. `interface Bad<A = string, B> {}` is rejected — the compiler's complaint is that required type parameters may not follow optional type parameters. Once you default any parameter, everything to its right must be defaulted too. This is not an arbitrary restriction; it falls directly out of how references work. Type-argument lists are positional and there is no placeholder for a skipped entry, so the only arguments a caller can omit are the trailing ones. A default on a middle parameter could never actually be used without also defaulting everything after it, so the language forbids the shape outright rather than letting you write something useless. ## Scope: a default may look left, never right The default is a type expression evaluated in the scope of the parameter list, and it can name parameters that were declared before it: ```ts interface Pageable<Item, Page = Item[]> { current: Page; } type A = Pageable<string>; // Page = string[] type B = Pageable<string, Set<string>>; ``` This is genuinely useful: the second parameter usually derives from the first, and defaulting it to that derivation keeps the common reference short while still allowing an override. Referring *forward* is an error — `interface Bad<A = B, B = string> {}` is rejected because a default may only reference previously declared type parameters. Self-reference is likewise circular and rejected. ## Constraints: order, and the satisfaction check When a parameter carries both a constraint and a default, the constraint is written first: ```ts type Ok<T extends string = string> = T[]; // type Bad<T extends string = number> = T[]; // default does not satisfy the constraint ``` The compiler checks the default against the constraint at declaration time, so a default that violates its constraint is an error on the declaration, not on some later use. The idiom `<T extends X = X>` — repeating the constraint as the default — is extremely common, and it says something precise: callers may narrow this parameter, and if they say nothing they get the widest type the constraint allows. It is the honest default for a parameter whose whole purpose is narrowing. A subtlety worth knowing: the constraint governs what a caller may *supply*, while the default governs what they *get* if they supply nothing. They are checked independently, which is why the satisfaction rule has to exist at all. The constraint mechanism itself — what `extends` means for a type parameter, what constraints buy you, how they shape inference — is a separate topic; here the only thing that matters is how a constraint and a default coexist on one parameter. ## What the rules add up to: legal arity The declaration decides the range of type arguments a reference may supply. With `interface Envelope<Payload, Meta = string>`, one parameter is required and one is optional, so a reference may pass one or two arguments; the compiler's error for a bad count phrases it as exactly that range. With no defaults at all, the count is exact. This is the practical, user-visible consequence of the position rule: the number of defaults is the size of the window. ## Naming, briefly The conventional single letters — `T`, then `U` and `V` for successive parameters, `K` and `V` for a key/value pair, `E` for an element — read fine on a one- or two-parameter generic where the reader can hold the whole signature in view. Past two parameters they stop helping, because a reference site shows only positions and the reader has to count. Library code therefore tends to use descriptive names with a `T` prefix, such as `TData` and `TError`, so that the declaration is self-documenting even though the call site is still positional. That is convention, not a compiler rule; the checker accepts any identifier. ## Erasure None of this survives compilation. Defaults, constraints and parameter names are all resolved during checking and then erased; the emitted JavaScript has no representation of a type parameter, so no rule here has any runtime cost or runtime meaning.