Why may a compiler-hosted processor add a companion type but not edit the declaration that triggered it?

## The rule A processor's output surface is **new files**. It can read the marked declaration in detail — its name, kind, modifiers, members, the values written into the marker — and it can emit as many new declarations as it likes. What it cannot do is reach back into the declaration it was triggered by and add, remove or change a member. That is the constraint every candidate has bumped into: *the marker is on my type, why did the tool put the generated method on a second type instead of on mine?* ## Why the model forbids the edit Three reasons stack up, and naming any two is a good answer. 1. **The declaration is already resolved.** The processor is not handed text; it is handed a symbol the compiler has already parsed, whose signatures have been resolved. Other declarations in the same compilation have been checked against that symbol. An edit would retroactively falsify checks that have already passed. 2. **Ordering would become semantics.** Several processors may be dispatched in one round. If each could mutate declarations, the resulting program would depend on the order they happened to run in — an order no source file states and no build tool guarantees. Add-only output is order-independent: whoever runs, the set of declarations only grows. 3. **Rounds are monotonic.** The loop that feeds each round's output into the next one relies on earlier declarations staying put. A declaration a processor inspected in round one is still the same declaration in round four. Mutation would mean a processor could observe a type that no longer exists by the time it emits against it. ## The workarounds, and what each costs | approach | what the author writes | what it costs | |---|---|---| | companion type beside the marked one | nothing, but call sites name the companion | the generated name leaks into every caller | | generated supertype the marked type extends | one declaration on their own type | spends the inheritance slot where a language has only one | | generated interface plus a hand-written one-line forwarder | one line per marked type | boilerplate the marker was meant to remove | | language-level partial or extension merging | a keyword on their type | only exists in some languages, so a shared tool cannot rely on it | | rewriting compiled output after the build | nothing | leaves the compiler's model: no source-anchored diagnostics, and another build step to own | The first two are the common ones. The last is the one teams reach for when they want the edit badly enough to leave the mechanism, and it is worth naming as a different mechanism rather than as a variant of this one. ## What the constraint actually buys It is easy to read the rule as a limitation, but it is the reason the model is safe to put in a shared build: - **You can read the source and know what a type declares.** A member you cannot find in the file does not exist on that type — a property that survives exactly as long as nobody can inject members. - **Results are reproducible.** With order-independent, add-only output, the same inputs produce the same outputs regardless of which processors were installed in which order. - **Failure is local.** A processor that goes wrong produces a bad new file, which fails to compile with an error pointing at that file, rather than corrupting a type that a hundred call sites depend on. ## The failure to recognise The characteristic bug is not an error but an absence. A team applies a marker expecting a method on their type, finds no method, and concludes the tool is broken. Nothing is broken: the tool generated a companion, and the call site has to name it. The second-order version is worse — a hand-written forwarder that drifts, because the generated companion gained a parameter and the one-line forwarder was written by hand and never regenerated. A processor author mitigates both by making the generated surface discoverable: a predictable name derived from the marked declaration, a generated supertype where the language and the team's inheritance budget allow it, and a diagnostic at the marked declaration whenever the tool decides not to generate. ## What this does not cover The rule is about the processing model, not about what any particular toolchain has bolted on. Some ecosystems ship mechanisms that *appear* to add members to a marked type; where that happens, the mechanism is not a processor obeying this model but a different one operating at another phase, with a different set of guarantees about diagnostics, incremental builds and what an editor can see. The distinction is worth drawing explicitly in an interview, because it is exactly the line between the model described here and the tools that break it.