Why does a reachable reflect.Value.MethodByName stop Go's linker from pruning methods?

## What the linker is trying to do Go links statically, so every byte of reachable code ships in the binary. `cmd/link` therefore runs a dead-code pass: starting from the entry point it walks the call graph and keeps only what can be reached. Direct calls are trivial to follow. Interface calls need a trick: the linker records which *method names* are called through interfaces anywhere in the program, and which concrete types are ever converted to an interface value. A method survives when a type that reaches an interface has a method whose name is called through some interface. Everything else — including exported methods nobody ever calls — is dropped. This is why a Go binary that imports a large package does not necessarily carry all of it. ## What reflection does to that reasoning `reflect.Value.MethodByName(name)` selects a method from a string that exists only at run time. The linker cannot evaluate that string; the name may be read from a config file, an HTTP request or an operator's terminal. So the proof "nothing calls this method" is no longer available for *any* exported method of a type that reflection could get hold of. The toolchain handles this conservatively. The compiler records that a package performs reflective method lookup, and once such a call is reachable from the entry point the linker stops pruning methods of reflect-reachable types and keeps their exported method sets. The same applies to `reflect.Type.MethodByName` and to the index-based `Value.Method`. Note the scope: this is a **program-wide** decision, not a per-type one. You cannot confine it by only ever dispatching onto one small handler struct. If `MethodByName` is reachable at all — including from a dependency you did not write — the conservative behaviour applies across the program. ## The symptoms - The binary jumps in size when the dispatcher lands, often noticeably in a service that pulls in large dependencies. - Deleting an unused exported method no longer shrinks anything, which is confusing in review: the diff removes code and the artefact does not change. - Size stays flat as the codebase grows dead weight, because nothing is dead any more. `go tool nm -size` on the two binaries, before and after, shows the retained symbols concretely; comparing symbol lists is more convincing in a review than the total size alone. ## The consequence that matters more than size Binary size is the visible symptom; the surface is the real one. Once dispatch resolves names from data, **every exported method on a dispatchable type is reachable from an operator-supplied string**. That includes methods added next month by someone who has never read the dispatcher and thinks they are writing an ordinary helper. Reflection cannot see unexported methods, so the export marker — previously a documentation decision — silently becomes a security boundary. ## What actually fixes it **Remove the reachable `MethodByName`.** An explicit registry does the same job with compile-time references: var commands = map[string]func(*Admin, string) error{ "drain": (*Admin).Drain, "cordon": (*Admin).Cordon, } Those method expressions are ordinary references, so pruning works, renames are caught by the compiler, and the set of dispatchable commands is exactly the set you can read on one screen. What does **not** work: - `-ldflags="-s -w"` strips the symbol table and DWARF. It shrinks the file but removes no code and changes nothing about which methods are callable. - Hiding the call behind a run-time condition. Reachability is static; an `if` that is always false still makes the call reachable. - Unexporting the methods you do not want dispatched. Reflection could never reach them anyway, and the conservative linker behaviour is triggered by the presence of the reflective call, not by which methods exist. ## How to talk about it in review The honest framing is a trade, not a bug: name-based dispatch buys you handlers that can be added without touching the dispatcher, and costs you dead-code elimination, rename safety and a bounded surface. On a small internal tool the cost is negligible. On a service where the binary ships to many machines, or where the exported method set is large and grows by contribution from several teams, it is the deciding argument.