Your registry requires a handler declared over exactly the route's payload type, and a working shared handler is rejected — what over-constrained the signature?

## The rejection The registry pairs a route with the handler that will receive its payload, and states the relation between the two placeholders as identity: ``` function register<Route, Payload>(r: Route, h: Handler<Payload>) requires Payload is the payload type that Route declares ``` A team then writes one auditing handler over a broad payload type — every payload that carries audit fields — and registers it on a dozen routes. Each route declares its own narrower payload, and each of those payloads is one of the broad ones. Every registration is rejected. The handler would work: hand it any of those payloads and it does the right thing. The signature refuses it anyway, and the error blames the caller for a decision the signature made. ## Identity is the strongest relation available Between two placeholders you may state a spectrum of relations, and identity sits at one end of it. | Relation stated between the pair | Which handlers are admitted | Which are refused | When it is the right choice | |---|---|---|---| | The handler's payload **is** the route's payload | only the exactly-matching handler | every broader handler that already works | the body needs to both give and take that exact type | | The route's payload is **acceptable to** the handler | the matching handler and any broader one | handlers too narrow to take the route's values | the body only passes the payload in | | No relation at all | every handler | none | there is no real pairing — usually a design error | The first row is not wrong in general. It is wrong **here**, because the body of `register` and everything downstream of it only ever moves a payload in one direction: from the route to the handler. Identity is what you state when values travel both ways. ## Find the weakest relation the body depends on The diagnosis is a mechanical exercise, and it is worth doing aloud in an interview. 1. **List what the body does with each placeholder.** Here: it stores the route, and it will later call the handler with a value of the route's payload type. 2. **Write down the requirement each of those operations actually imposes.** Calling the handler with that value requires only that the handler accepts it. 3. **Compare that with the relation the signature states.** Identity is strictly stronger than acceptance, so the gap between the two is exactly the set of callers being refused for no reason. 4. **Restate the relation at step 2's strength** and re-check every existing call site still compiles — weakening a relation never breaks an existing caller, it only admits more. Step 4 is the reassuring part: loosening a dependent pair is a safe edit in a way that tightening one never is. ## Three fixes that are worse than the problem - **Widening the handler's own declaration** so its payload type matches this route exactly. This makes one call site compile by making the handler less reusable everywhere else, and it does not scale past the second route. - **Dropping the second placeholder** and passing the payload through a common supertype, with the body checking at run time. That deletes the pairing the registry existed to enforce and converts a rejected call into a production failure. - **Keeping identity and adding an escape hatch** — a body-level conversion or an unchecked pass-through for the cases the checker refuses. That leaves the over-constrained signature in place as the documented contract while the code quietly violates it. All three treat the signature as fixed and the callers as the problem. The signature is the thing you control. ## Reading over-constraint in review A dependent pair is over-constrained when the relation it states is stronger than the operations in the body require, and the symptom is always the same shape: - a caller with a value that demonstrably works is refused; - the refusal names a type relationship rather than a missing capability; - the caller's workaround is to make its own type worse. That last symptom is the reliable one. When accommodating a signature makes a caller's code less useful to its other users, the signature asked for too much. Note also the direction: the failure is on the **consumer** side, where a broader declared type is the more capable one. The same signature with the payload flowing outwards would fail in the opposite direction, and identity would be over-constraining there too, just for the mirror-image reason. ## The rule worth carrying Every relation you state between two placeholders is a set of callers you have forbidden, and you owe each one a reason drawn from the body. Say identity when the code genuinely both produces and consumes that type; say acceptance when it only passes the value in; say nothing when the two were never related. Strength in a signature is not rigour — it is a bill the caller pays.