In TypeScript, given `interface Comparable<U> { compareTo(other: U): number }`, what does the self-referential constraint in `function max<T extends Comparable<T>>(a: T, b: T): T` express, and when do you need it rather than `T extends Comparable<unknown>`?

## What the constraint says ```ts interface Comparable<U> { compareTo(other: U): number; } function max<T extends Comparable<T>>(a: T, b: T): T { return a.compareTo(b) >= 0 ? a : b; } ``` The bound of `T` mentions `T`. Read it as a recursive requirement: a type may be used here only if it can be compared *against its own type*. This shape is classically called **F-bounded polymorphism**, and it appears wherever a contract's method must speak about the implementing type rather than about some fixed type. ```ts class Money implements Comparable<Money> { constructor(readonly cents: number) {} compareTo(other: Money): number { return this.cents - other.cents; } } max(new Money(5), new Money(9)); // T = Money ``` ## Why not `Comparable<unknown>` The two constraints are not stronger and weaker versions of one idea; they say different things. `Comparable<unknown>` requires a `compareTo` that will accept *any* value at all — a much heavier obligation, and one that pushes the implementer back into runtime checks. And it still would not connect the parameter type to the receiver: nothing in that bound guarantees that `b`, which is also a `T`, is an acceptable argument for `a.compareTo`. The self-reference is what makes the body type-check for the right reason. ## Why self-reference is legal A constraint is not evaluated eagerly. When you call `max(x, y)`, TypeScript infers `T` from the arguments and then checks the inferred type against the bound with `T` substituted — one assignability check, no recursion. That is why `T extends Comparable<T>` resolves fine, and why the same trick works for recursive data shapes: ```ts interface TreeNode<T extends TreeNode<T>> { children: T[]; } ``` Here the constraint preserves the *specific* node type through the structure, so a consumer of a `MyNode` tree gets `MyNode` back from `children`, not the base shape. ## Why TypeScript needs it less than nominal languages Two reasons. First, **structural typing**: any object with a matching `compareTo` satisfies `Comparable<Money>` without declaring that it implements anything, so a lot of code simply takes the concrete shape it needs and skips the abstraction. Second, for the "return my own type" case — the classic motivation in nominal languages — TypeScript has the polymorphic `this` type available inside classes, which handles many builder- and chain-shaped APIs without an extra type parameter. ## Costs to weigh F-bounded constraints are load-bearing but noisy. Every consumer of the API sees the recursive bound in tooltips and in emitted declarations, and inference failures produce error messages that mention the constraint twice. If the only thing you need is "has a `compareTo` for this concrete type", write the concrete type. Reach for the self-reference when the *relationship* is what you are abstracting over and callers really will instantiate it with many different types. ## Erasure The constraint contributes nothing to the output. `max` compiles to a function that calls `compareTo` and returns one of its arguments; there is no check that the operand types match, and if a value reaches it through `any` or an assertion, the comparison runs anyway. As with every constraint, it disciplines the call sites the compiler can see. ## Interview framing "The bound mentions its own parameter, so it requires the type to be comparable with itself — that is what makes `a.compareTo(b)` valid when both are `T`. `Comparable<unknown>` would demand a method accepting anything and still would not relate the argument to the receiver. It resolves fine because constraints are checked after inference substitutes `T`. I use it sparingly in TypeScript, since structural typing and polymorphic `this` cover many of the cases nominal languages need it for."