In a registry signature where the payload placeholder must be the type the chosen route declares, what does the caller actually choose?
answer
- two names, one choice
- the second is derived, not picked
- the relation runs one way
- route decides payload, not the reverse
- mismatch rejected at the call site
basics
~20 sA caller chooses the route only. When one placeholder is expressed through another, that single choice settles both positions: the payload is determined rather than chosen, and a payload argument that disagrees is rejected at the call site.
solid answer
~50 sTwo placeholders in a signature do not always mean two choices. Here the second is expressed through the first — the payload is whatever the chosen route declares it carries — so the caller picks the route and the payload placeholder is then solved, not selected. That dependency runs one way: a route decides its payload, but several routes may declare the same payload, so naming a payload does not name a route. The practical consequences are that a caller cannot pair a route with an unrelated payload, that the mismatch is reported at the call site rather than somewhere inside the body, and that the checker usually solves both arguments from the values passed in, leaving the caller to write neither. The cost is real: one choice now settles two positions, and the caller pays for it whenever a value that would have worked is not the exact type the route declares.
code
pseudocode · 10 lines// the payload placeholder is not free: the route declares what it carries
function dispatch<Route, Payload>(r: Route, p: Payload) -> Outcome
requires Payload is the payload type that Route declares
dispatch(orderRoute, orderPayload) // accepted: orderRoute declares OrderPayload
dispatch(orderRoute, userPayload) // rejected while checking the call; body never runs
// the dependency runs one way only:
// orderRoute and archiveRoute may both declare OrderPayload,
// so a payload on its own names no single routego deeper
Take away one habit: count the relations in a signature, not just the placeholder names. Two names with one expressed through the other still leaves the caller a single decision to make.
Explain the mechanics: which placeholder is solved first, which is derived from it, why the relation is one-way, and why a mismatched pair is rejected while the call is checked rather than when the body runs.
Show the cost side. Say who is inconvenienced by the dependency, name the case where a usable value is refused, and be clear that fixing it means changing the signature rather than the call.
Treat each stated relation as a combination you have permanently forbidden across every consumer. Decide deliberately whether the guarantee the body gains is worth the flexibility every caller loses.
## Two shapes that read alike A signature carrying two placeholders can be either of two very different things, and both look identical at a glance: - **An independent pair.** `function dispatch<Route, Payload>(r: Route, p: Payload)` — any route may be paired with any payload. Two placeholders, two free choices. - **A dependent pair.** The same two names, plus a stated relation: `Payload` is the payload type that `Route` declares it carries. Two placeholders, **one** free choice. The count of placeholders tells you how many names the signature introduces. It does not tell you how many decisions the caller gets to make. That is why reading the relation between them is the whole skill here. ## Which way the dependency runs The relation is **one-way**, and stating it backwards is the most common error in this material. - A route decides its payload: choosing the route leaves exactly one admissible payload type. - A payload does **not** decide a route: several routes may declare the same payload type, so a payload names no single route. So the free placeholder is the one the other is expressed through, and the derived one follows. If you find yourself saying the caller "picks the payload and the route is inferred", check the relation again — it usually points the other way. ## What the caller experiences | | Independent pair | Dependent pair | |---|---|---| | Free choices at the call site | two | one | | What the checker must solve | two arguments, from the values | one argument, the other derived from it | | Where a mismatched combination shows up | nowhere — every combination is legal | at the call site, before the body runs | | What the body may assume | nothing linking the two | the payload is the one this route declares | | Who pays when a usable value is rejected | nobody; nothing is rejected | the caller | The row that matters in an interview is the last one. A dependent pair is the **stronger** statement, and strength is not free — every relation you state is a combination you have forbidden. ## Where a mismatch surfaces Give a route one payload and hand it another, and the checker cannot solve the dependent placeholder consistently: the route says one type, the argument supplies another, and the call is rejected. Two properties of that rejection are worth saying out loud in an answer: 1. It happens **while the call is being checked**, not inside the body. No line of the function runs, and the error names the call, not an operation four frames deeper. 2. It happens **once per call site**, so the same mistake cannot reappear later on the read path or in a different thread of execution. The alternative design — two independent placeholders, with a comment saying which payload belongs to which route — moves that check to run time, if it happens at all. That is the trade the dependency buys. ## What the caller usually has to write A dependent pair does not normally force explicit type arguments. Where the call passes a route value and a payload value, the checker solves the first placeholder from the route and derives the second, and the caller writes no type arguments at all. Explicit arguments become necessary in the usual places — when the call passes nothing the first placeholder can be solved from, or when the result is the only thing that would pin it. Those are inference's own limits, not a property of dependency. Ordering does matter in one respect: the derived placeholder has to be able to refer to the one it is expressed through, so the relation is written after the thing it depends on. The declared order of the two names is otherwise just what explicit callers must type, in that order. ## Why an interviewer asks this Because a dependent pair is the exact point where a signature starts to speak for the caller. The interviewer wants three things in the answer: - that you noticed the second placeholder is not a second choice; - that you can say which direction the dependency runs, and why the reverse does not hold; - that you can name what it costs — a caller with a perfectly serviceable value that is not the exact declared type is now stuck, and the fix is a change to the signature rather than to the caller. The short form of the whole answer: **placeholders count names; relations count choices.**
- Does a dependent pair mean the caller must spell out both type arguments?No. Where the call passes a route value, the checker solves the first placeholder from it and derives the second, and the caller writes nothing. Explicit arguments are needed only in inference's usual dead ends — a call with nothing to solve the first placeholder from, or one where only the result would pin it.
- What does the body gain from the dependency that an independent pair could not give it?A guarantee it does not have to check. With the relation stated, the body may pass the payload straight to whatever the route declares handles it, because no other combination could have reached that line. With an independent pair the body has only two unrelated values and must verify the pairing itself or trust a comment.
- How would you tell, from a signature alone, whether a pair is dependent?Ask whether either placeholder is described in terms of the other — as a relation clause, a derived member, or a limit written against the other name. If each is introduced on its own and nothing mentions the other, the pair is independent, and every combination of arguments is legal however unlikely it looks.
A form where choosing the country decides which list of regions the next field will accept. The second field is still on the form, but it stopped being an independent choice the moment the first one was made.
saying these in an interview costs you the question
- Treats a dependent placeholder as a second free choice for the caller
- Says the dependency runs both ways, so a payload determines its route
- Expects the mismatch to surface inside the body rather than at the call site
- Believes a dependent pair always forces the caller to write type arguments explicitly
- Claims the relation constrains only the implementation and never the caller