When a generic host rejects a candidate type, how does a missing-member failure differ from a missing-supertype failure in what it tells the author?
answer
- one fact versus a comparison
- which type, or which operation
- blunt but complete fix
- partial match reports the delta
- wide shapes recurse into long reports
basics
~20 sA missing supertype is one fact — the declaration is absent — so the report names the type to implement and cannot say which operation was wanted. A missing member is a diagnosis: the checker names the operation and the signature that failed.
solid answer
~40 sUnder a named requirement the checker knows only that the candidate's declaration does not mention the required type. The report is short and the remedy is single and blunt: declare it, or wrap it. It cannot tell the author which operation the host actually needed, and if the type is not theirs to edit, it points at a fix they cannot apply. Under a shape requirement the checker compares member by member, so it can name the operation that is absent or the signature that disagrees, which localises the defect precisely. The costs run the other way: a wide or nested shape produces a long report, the mismatch can surface far from the type's own declaration, and fixing one member may only reveal the next, so rejection is diagnostic but not complete.
code
pseudocode · 15 linesrequires T has {
name() -> Text
run(input: Bytes) -> Bytes
cancel() -> Unit
}
type Minifier {
function name() -> Text { ... }
function run(input: Bytes) -> Bytes { ... }
// no cancel
}
// supplying Minifier as the type argument is rejected.
// the shape rule can say: cancel() is missing; the other two matched.
// a named rule could only say: Minifier is not declared as a Step.go deeper
Recall that a type can be refused for two different reasons: it never declared the required type, or it lacks an operation the requirement lists.
Explain what each report can and cannot say — the absent declaration carries no operation name, the member comparison carries the exact one — and why one fix settles everything while the other may iterate.
Judge the failure from the receiving author's seat, especially one who cannot edit the candidate, and shape the requirement so its rejections stay short and actionable.
Treat the rejection as published surface: it drives support load, review visibility and how a change to the requirement reaches teams you may not be able to enumerate.
## Two different kinds of "no" The rejection message is part of the contract you ship to add-in authors, and the two forms of requirement fail in structurally different ways. A **named requirement** fails on a single fact: the candidate's declaration does not mention the required type. There is nothing else for the checker to compare, because conformance under this rule is a statement, not a measurement. A **shape requirement** fails on a comparison: the checker walks the operations the requirement lists against the members the candidate has, and reports where the walk broke — an operation that is absent, an arity that differs, a parameter or result type that does not line up. ## What the named failure gives the author - **One fact and one remedy.** Declare the supertype, or pass an adapter that declares it. This is blunt but *complete*: once the declaration exists and compiles, every operation of that supertype is settled at once. - **No statement of need.** The message says which type is missing, not which operation the host wanted, so an author who does not already know the published type must go read it. - **A remedy the author may not be able to apply.** If the type is generated, vendored or owned elsewhere, "implement this type" is advice about someone else's code. - **A stable place to improve the message.** Because the requirement is a published declaration, its documentation, its name and its version travel with the failure. ## What the shape failure gives the author - **The exact delta.** A partial match is reported as a partial match: three of four operations satisfied, and the fourth named. That is often enough to fix without reading anything. - **A mismatch, not just an absence.** A member that exists with the wrong signature is a different and more useful report than "not conformant". - **Volume.** A wide shape, or one whose operations take further shapes as parameters, produces a report that recurses; the useful line can be buried. - **Distance.** The failure is raised where the type argument is supplied, which may be far from where the candidate is declared and far from the team that owns it. - **Incompleteness.** Fixing the reported member can expose the next one, so the loop is iterative rather than one edit. ## Side by side | Aspect | Missing supertype | Missing member | |---|---|---| | What the report names | the type to implement | the operation or signature that failed | | Number of facts | one | as many as the mismatch has | | The fix | one declaration, or an adapter | add or change the member, or choose another type | | After the fix | the whole requirement is settled | only the reported member is settled | | Ambiguity | none about *what* to do | some: fix the candidate, or was it never meant to fit? | | Useful to a non-owner | little; the fix is not theirs | more; it says exactly what a wrapper must supply | The row that decides most arguments is the last one. An author who cannot edit the candidate has to write a wrapper either way, and the shape failure has already told them what the wrapper must contain. ## Why this matters beyond ergonomics 1. **It shapes your support load.** A host whose rejection says "declare our published type" will be asked, repeatedly, *why* — because the message carries the requirement's name but not its purpose. 2. **It shapes review.** A named conformance is visible in the candidate's declaration, so a reviewer can see an intent to be an add-in. A shape match is visible nowhere, so review has to look at the use site. 3. **It shapes migration.** When you add an operation to the requirement, the named form breaks a list of implementers you can notify in advance; the shape form breaks conformers you cannot enumerate, and they find out by compiling. ## What an interviewer is listening for - That you state the direction correctly: the named failure reports an **absent declaration**, the shape failure reports an **absent or mismatched member**. - That you notice the named failure is blunt but complete, and the shape failure is precise but iterative. - That you connect the message to the person receiving it — particularly the author who does not own the candidate type.
- Why is a rejection under a named requirement described as blunt but complete?Blunt because it reports one fact — the declaration is absent — and says nothing about which operation the host wanted. Complete because the single remedy settles the whole requirement at once: once the candidate declares the published type and compiles, every operation that type demands is accounted for, with no second round of failures waiting behind the first.
- Your shape requirement produces enormous rejection messages. What in the requirement caused that?Width and nesting. Every operation listed is a line the report can fail on, and an operation whose parameter or result is itself described as a shape makes the comparison recurse, so one mismatch deep inside prints the whole surrounding structure. Narrowing the requirement to the operations the body genuinely calls shortens both the contract and its failures.
saying these in an interview costs you the question
- Says the named-supertype failure reports which operation was missing.
- Claims a shape failure always identifies a single fix.
- Thinks fixing one reported member guarantees the next check passes.
- Assumes rejection messages are cosmetic rather than part of the contract.
- Believes a wide shape costs nothing because the body calls only part of it.