What standard would you set for a shared library on whether routines declared over an unknown type may inspect it?

## The decision being made A library used by many teams has to choose a default for one question: may a routine declared over a type it does not name find out what that type is and behave differently? The answer is a standard, not a preference, because whichever way it goes it is applied by people who will never meet each other. The case for **uniform by default** is about who pays for review. When a body cannot inspect its type argument, the declaration bounds what the body can do, and that bound holds for every caller, every type argument, and every future change that keeps the declaration. Review scales, because reading the declaration is the review. When inspection is permitted, correctness becomes a per-type property, and someone has to establish it for each type and re-establish it whenever a new one appears. ## What the rule buys and what it costs | | Uniform by default | Inspection permitted freely | |---|---|---| | Reviewing a call site | the declaration is enough | read the body with this type in mind | | A type argument nobody anticipated | provably no new path | a new, unexercised branch | | Tests needed | correct once, correct for all | one per supported type | | Rewrites across the routine | licensed by the declaration | re-established by hand each time | | Cost at the call site | operations must be passed explicitly | the body guesses, callers write less | | Cost to the library author | more arguments, more ceremony | branches that accumulate quietly | The last two rows are the honest price of the rule. Uniform code pushes work outward: if a routine needs to know how to compare, format or encode something, the caller has to hand that over instead of the body inferring it. That is more typing and, for a while, more friction. What you get back is that nobody ever has to ask what the routine does for a type they just invented. ## Exceptions worth carving out deliberately A blanket ban with no exceptions is the version of this standard that gets quietly ignored, so name the categories up front: - **Boundaries where values leave the type system** — encoding for storage or transport, and the decoding that comes back. Behaviour genuinely has to depend on what the value is, and banning it there only pushes the same decision into every caller, where it is harder to see and duplicated. - **Layers whose whole job is to choose an implementation by type.** If that is the routine's purpose, it is not uniform code with a shortcut in it; it is dispatch, and it should be declared and named as such. - **A measured, isolated performance decision**, kept behind a declaration that is otherwise uniform and accompanied by evidence that the difference mattered. Everything else — a missing argument guessed from the type, a nicer error message, a convenience for one caller — should go back and be passed in. ## Making the standard hold A standard nobody can apply is a document, not a rule. Four things make this one applicable: 1. **A default in writing, with the reason attached.** "Uniform unless listed" beats "avoid run-time type tests", because the second invites a case-by-case argument every time. 2. **A naming and documentation convention** so that a type-directed routine is visibly type-directed, with its behaviour per type and its fall-through case written down. 3. **A test expectation** — a case per supported type argument for anything that inspects, and explicitly no such matrix for anything that does not. 4. **One review question**, asked every time: could this branch be an argument the caller supplies? Most exceptions dissolve at that question, and the ones that survive are the real ones. ## Knowing whether the standard is right Set out in advance what would change your mind, because a standard that cannot be wrong is not being tested: - **If the exception list keeps growing**, the problem is probably the abstraction, not the rule — the library is being asked to do something its declarations cannot express, and the fix is to change what callers pass rather than to loosen the default. - **If defects cluster in the inspecting routines**, the rule is paying for itself and is worth tightening. - **If teams route around the library** because the ceremony is too high, the cost side of the table is winning and the default should be revisited for the surfaces where that is happening. The judgement being asked for here is not "inspection is bad". It is knowing which of these two currencies — reviewer attention across many teams, or convenience at the call site — is scarce in your organisation, and setting the default for the scarce one.