In TypeScript, `function longest<T>(a: T, b: T) { return a.length >= b.length ? a : b; }` does not compile. Why does the checker reject `a.length`, and what does changing the signature to `<T extends { length: number }>` change?

## Why an unconstrained type parameter is opaque A generic function is checked **once**, not once per call. When you write `<T>`, `T` is a placeholder that the caller — not the function — chooses. The compiler must therefore prove the body is safe for *every* type the caller could pick: `string`, `number`, `null`, a class instance, a union. The only members it can safely admit are the ones every one of those types has, and that set is empty. An unconstrained type parameter behaves as if it were constrained to `unknown`. So this is rejected: ```ts function longest<T>(a: T, b: T) { return a.length >= b.length ? a : b; // ~~~~~~ Property 'length' does not exist on type 'T'. } ``` The error is not that `length` is missing from the *value* you happen to pass — it is that the signature never promised it. ## What `extends` means in this position `extends` in a type-parameter list is **not** class inheritance. Read it as *"is assignable to"*: `T extends C` means "whatever the caller substitutes for `T` must be assignable to `C`". TypeScript's assignability is structural, so the constraint describes a *shape*, not an ancestor. The constraint is a bargain with two halves: - **Call sites lose freedom.** Arguments that are not assignable to the constraint are rejected there, with an error like `Argument of type 'Map<any, any>' is not assignable to parameter of type '{ length: number; }'. Property 'length' is missing in type 'Map<any, any>'`. - **The body gains knowledge.** Inside the function, every value of type `T` may be treated as having the constrained members. ```ts function longest<T extends { length: number }>(a: T, b: T): T { return a.length >= b.length ? a : b; } longest("alpha", "be"); // ok — string has length longest([1, 2], [1, 2, 3]); // ok — arrays have length longest({ length: 3 }, { length: 9 }); // ok — structural ``` ## Which types satisfy `{ length: number }` Because the check is structural, the qualifying set is wider than people expect: `string`, every array and tuple type, functions (a function's `length` is its arity), and any object with a numeric `length` property — including one that carries extra properties, since `T` is inferred as the whole argument type. `Map` and `Set` are rejected: they expose `size`, and a structural check does not care that the *idea* is similar. ## The constraint is a floor, not the type of the value A very common misreading is that `T extends { length: number }` turns the parameter into `{ length: number }`. It does not. The constraint is the minimum the body may rely on; inference still resolves `T` to the argument's real type, so the caller's specificity survives the call when you return `T`: ```ts declare function longest<T extends { length: number }>(a: T, b: T): T; const s = longest("alpha", "be"); // s: string ``` ## The escape hatches, and why they are worse Two shortcuts remove the error without the guarantee. Typing the parameters as `any` silences every member check, including the typos; and asserting `(a as { length: number }).length` is an unchecked claim the compiler simply trusts. The constraint gives the same body access while keeping call sites honest. ## Constraints are erased Nothing about this survives compilation. The emitted JavaScript is the function body with the annotations stripped — there is no runtime test that the argument has a `length`. If a value reaches the function through `any` (a `JSON.parse` result, an untyped third-party call), the compile-time promise was never checked and the property access can be `undefined` at runtime. Validating untrusted data at the boundary is a separate job the type layer does not do for you. ## Getting the error message right When the constraint is wrong you get one of two very different errors, and knowing which is which speeds up debugging: a `Property 'x' does not exist on type 'T'` error inside the body means the **constraint is too loose** for what you are doing; an `Argument of type '…' is not assignable to parameter of type '…'` error at a call site means the **constraint is too tight** for what your callers have.