Why would a platform add parameterized types by checking the arguments and then discarding them from the compiled artifact?

## The decision in one sentence A platform adding parameterized types has to answer one question about the compiled artifact: does the type argument go into it, or does the compiler verify the argument and then leave it out? Leaving it out - **discarding**, or **erasure** - means the running program holds a value with no record of what it was declared to contain. That is not a shortcut the compiler took because the work was hard. For a platform that already has a large body of compiled code in the field, it is the choice that makes the feature adoptable at all. ## Erasure is a claim about the artifact, not about checking Before anything is dropped, the compiler does the whole job: - it verifies every insertion, argument, assignment and return against the declared argument; - it rejects the mismatches it can see, at build time, before the program exists as something runnable; - it inserts whatever narrowing the erased shape needs so the body still behaves correctly; - it keeps the declared shape available for its own later compilations, so a *separate* module compiled against the same declaration is checked the same way. A candidate who says the arguments are dropped because the compiler could not check them has the order backwards. The check is the entire purpose of writing the argument down, and the discard happens **after** the check has succeeded. Nothing is deferred to run time by this choice; what happens at run time is that no evidence remains. ## Why a platform with history chooses to discard Three pressures, roughly in the order a designer feels them. 1. **The installed base is already compiled.** Picture a crew-rostering system a decade old: rosters, shifts and bids all move through unparameterized collections, in artifacts that are deployed and that their owners will rebuild on their own schedule, not the platform's. New parameterized code must call those routines, and those routines must call back into new code. If a parameterized value were a *different* run-time entity from the one they were compiled against, neither direction would link, and the feature would be usable only in programs rebuilt from scratch. 2. **The run-time system is the most expensive component to change.** Discarding means it learns nothing new: same value representation, same containers, same linking rules. The feature lands entirely in the compiler - the component a platform can revise most cheaply, and the one users adopt one build at a time rather than one deployment at a time. 3. **Adoption has to be gradual, and gradual has to be cheap.** One compiled body per declaration means the artifact does not grow with the number of types a program parameterizes over. A team can parameterize the roster module this quarter and the bidding module next year, and every intermediate state is a program that builds, links and runs. ## The bill, both ways | | Discard after checking | Keep available while running | |---|---|---| | Compiled bodies | one, shared by every instantiation | one plus carried evidence, or one per instantiation | | Run-time system | unchanged | must model parameterization itself | | Existing artifacts | keep linking in both directions | may need rebuilding or conversion at the boundary | | Guarantee | static only, as far as the compiler saw | observable by the code while it runs | | Per-operation work | none added | storing, propagating and comparing metadata | ## What the discard costs The guarantee becomes purely static, which means it is exactly as strong as the compiler's view and no stronger: - a value arriving from code that was compiled without arguments carries no check, and nothing re-checks it on the way in; - any operation whose meaning depends on knowing the argument while the program runs cannot be expressed directly, and the body has to be handed that information some other way; - a mistake made at an unchecked boundary is discovered by whoever later reads an element out, not by whoever put the wrong one in, so the report is far from the cause. None of that is accidental either. The platform knowingly accepted a weaker run-time guarantee in exchange for a migration its users could actually perform. Platforms differ here: some discard the arguments after checking, some keep them reachable while the program runs, and the split usually tracks whether the platform had an installed base to carry forward when the feature was designed. ## Saying it in an interview The answer that sounds senior is a trade with both columns filled in, not a complaint. Name what was bought - one body, an unchanged runtime, both call directions preserved, module-by-module adoption - and then name the bill: a guarantee that stops at the edge of what the compiler could see. An answer that only lists the restrictions has described the symptom and missed the decision.