When a placeholder carries several requirements, what type do you write to store or pass on a value satisfying all of them?

## The value has a type nobody wrote Inside a routine whose placeholder is required to be both orderable and renderable, a departure value is simultaneously usable as each. Its type is the **combination** of the two requirements: the set of types satisfying both, carrying the union of their operations. No declaration in the program introduces that type, and in many type systems no syntax exists to write it anywhere except the position that declares the placeholder's requirements. This is what makes the subject a real interview question rather than a syntax note. The combination is easy to demand and awkward to keep: every time the value leaves the routine that demanded it, the type system needs somewhere to record that both requirements still hold. ## Three ways to keep both requirements | Way | What you write | What it costs | |---|---|---| | Propagate the placeholder | the helper declares its own placeholder with the same requirement list | the list is repeated at every signature that handles the value | | Write the combination directly | a type position naming both, where the type system allows it | only available where first-class combined types exist; long to read | | Introduce a named type | one declared type carrying both capabilities | every candidate type must be declared under it, which you may not control | Propagation is the default answer and the one an interviewer is listening for. The helper is generic too; its placeholder is inferred from the argument at the call site; both requirements travel because the helper demanded both. Nothing is cast, nothing is checked again. Some type systems do provide a combination you can write in any type position - a field, a variable, a return type. There the problem dissolves, and what remains is readability: the full list appears at every position, and diagnostics print the whole thing. ## What widening costs The tempting shortcut is to store the value under one of its requirements - the ordering contract, say - and carry on. The value itself does not change: at run time it still has every operation it always had. What changes is what the type system knows. Once the variable is typed by one requirement, the other requirement's operations are no longer reachable, and getting them back means an **unchecked narrowing** the compiler cannot verify. That converts a guarantee the caller already established into a possible failure at the point of use, and it does so silently, far from the call site that had the information. The same applies to widening all the way to a universal root type and testing at run time: it compiles, it is slower, and it throws away a fact the signature had already proved. ## At the compiled boundary Where a type system discards type arguments after checking them, the placeholder is compiled to one representative - the first entry in the requirement list - and conversions are inserted where members of the other entries are reached. That is invisible to the source, and it does not weaken the guarantee: the check already happened at the call site, and the inserted conversions are known to succeed. It does mean that a value of a combined type has no single run-time name to inspect, and that the combination is not something a run-time test can ask about as a whole. Where a type system keeps type arguments available instead, more of the structure survives, but the source-level naming problem is the same. ## Practical rules 1. Reach for propagation first: give the receiving routine the same requirement list and pass the value straight through. 2. If the list is repeating across more than a handful of signatures and you own the candidate types, that is the evidence for introducing a named type carrying both - not aesthetics. 3. Never widen and narrow back inside the same call chain; if you wrote a narrowing that you know cannot fail, the signature above it lost information it should have kept. 4. For a long-lived field, decide deliberately. A field needs a nameable type, so the options are a first-class combined type where the language has one, a named carrier type, or two fields holding the value under each requirement - which is a duplication that can drift. 5. Keep the list short. Each extra requirement is repeated at every signature the value passes through, so the naming problem grows with the list, not with the number of call sites.