A precompiled generic decoder ships as a binary: under which strategy can a caller use a sample type the library's build never saw?

A platform team ships a telemetry decoder as a library: other teams link it into their field controllers and use it with their own sample types. Whether that library can be a finished binary is decided entirely by which compilation strategy the platform uses for generic bodies — this is the point where the two strategies stop being an optimisation detail and become a packaging decision. ## Why a precompiled artifact is where they part A copy of a generic body exists only where a compiler produced it. A binary is the output of compilation, not an input to it: linking can resolve a reference to a copy that already exists, but it cannot manufacture one that was never emitted. So a library built under per-argument generation contains exactly the copies its own build enumerated, and no more. A shared body has no such limit, because it was never tied to a type in the first place. It works from a table of operations that arrives at the call, and a table for a sample type invented years later looks the same to it as a table for one that existed on the day it was compiled. ## What the shared-body strategy lets you ship - A finished binary, complete for every argument type including ones that do not exist yet. - A stable boundary: a change confined to the inside of the generic body reaches consumers by replacing the artifact and re-linking. - Build cost paid once, by you, not repeated in every consumer's build. What you give up is tuning. The body was compiled without knowing anything about any caller's type, so no width is folded, no layout is exploited, and every operation the caller supplies is an indirect call. ## What per-argument generation forces into the distribution 1. **The body itself must ship** in a form the consumer's build can compile — source, or an intermediate representation the toolchain accepts. A binary alone is not enough. 2. **The consumer's build does the generation**, so compilation time for your generic code lands on their machines and scales with how many argument types they use it with. 3. **A change inside the body requires consumers to rebuild**, not merely re-link: their copies were generated from the old body and will keep being the old body until something recompiles. 4. **The body's internals become observable.** Whatever you shipped for compilation is readable, and details you would have called private are now things people can read and reason about. 5. **The generated copies live in the consumer's image**, so the space they occupy is spent from the consumer's budget, not yours. There is a middle path worth knowing: a library on such a platform can pre-generate copies for an enumerated set of argument types it chooses to support and export those, so callers using one of the supported types link normally. Callers with anything else cannot build unless the generic body itself is available. That turns *the supported set of argument types* into a published part of the contract — something the library must version and deprecate like any other API surface. | | shared body shipped as a binary | generated per argument | |---|---|---| | unfamiliar argument type | works | impossible without the body | | what the distribution contains | a finished binary | the body in re-compilable form | | who pays the compilation | the library's build | every consumer's build | | effect of a change inside the body | replace and re-link | consumers rebuild | | tuning to a caller's type | none | full | ## What to ask when you own the library The useful questions are about the population of callers, not about benchmarks. Do the argument types come from a small set you can enumerate, or does any team bring their own? Can every consumer rebuild on demand, or are some of them shipping images you cannot make them recompile? Do the operations run once per frame or once per sample? A library whose argument set is genuinely open and whose consumers cannot all rebuild has effectively one option, whatever the profile says. ## What an interviewer is checking That you can carry the mechanism into a packaging consequence without being told to. The short answer is "the shared-body strategy", and it is worth little on its own. The answer worth points continues: because a copy has to be compiled by someone, per-argument generation moves compilation into the consumer's build, which is why libraries on such platforms ship their generic bodies rather than only binaries, and why a change inside one of those bodies is a rebuild for everyone downstream rather than a drop-in replacement.