An API deprecation should come with a migration
Go’s source-level inliner lets package authors supply API migrations. Learn where wrappers help, what review must preserve, and when manual edits win.
By 
Paul. Languages and frameworks
Deprecating a public API transfers work to every team that depends on it. For a simple replacement, the maintainer should consider supplying the migration alongside the replacement. A wrapper that expresses the old operation through the new API can carry executable migration knowledge. That support belongs in the API contract because consumers must understand both how to use a package and how to leave its older interfaces.
Go provides a concrete mechanism. Its 10 March 2026 inliner article describes //go:fix inline, a directive through which package authors can make suitable calls eligible for source rewriting. The important distinction is permanence: this changes the source people maintain. Compiler inlining changes an intermediate representation while producing a binary. A successful source migration says nothing by itself about faster execution.
The wrapper explains the replacement
A deprecation notice can name a successor while leaving the relationship unclear. Consumers still have to determine whether arguments move, defaults change, or return values need adaptation. When an old function delegates to a new one, its implementation can make that relationship explicit. The maintainer then has a single place to express a replacement instead of asking each consumer to reconstruct the intention from prose.
This works best when the replacement really preserves the old operation. A migration that requires a product decision needs more than an executable wrapper. Choosing a different timeout policy or deciding how to handle a newly possible failure remains application work. Calling that work automatic would hide the part that matters most. Documentation should name the decisions the wrapper cannot make, including any reason to postpone the migration.
Treat the wrapper as maintained public code. If the new API later changes, the old entry point still represents a promise to its remaining users. Keeping it available while providing a migration gives those users a route forward without making every dependent application move on the maintainer’s schedule. It also creates an obligation to keep the old and new behavior aligned for the cases the migration covers.
Review the permanent result
Source rewriting deserves the same attention as another code change. A reviewer should be able to explain why the resulting calls retain the intended behavior and why any extra local variables remain necessary. Readability matters because the rewritten code becomes the starting point for later edits. A technically conservative result may be correct yet require cleanup before it becomes comfortable application code.
The February 2026 introduction to go fix supplies the broader context for this tooling. It also makes clear that analysis runs against a particular build configuration. The engineering implication is that reviewing one set of edited files cannot establish what happens in every supported platform configuration. Teams should choose coverage that reflects their own supported builds rather than assume a single rewrite sees the whole repository.
Effects deserve particular care. The March explanation discusses why substituting arguments can change evaluation order or repeat work. A migration must preserve the behavior of those expressions, not merely leave matching types. The tool may retain bindings to avoid unsafe substitutions. That is a reason to understand an unfamiliar result before simplifying it. Removing an apparently redundant variable can discard the protection that made the rewrite valid.
Review also separates the maintainer’s intention from the consumer’s acceptance. Publishing a directive does not give a library author authority to approve changes in another team’s application. The consumer still decides when to adopt them and which application checks justify release. Migration support reduces repeated interpretation; it cannot transfer responsibility for the application’s behavior back to the library.
A manual migration can be cheaper
The strongest objection is economic. A small library may have only a few known callers. Writing and maintaining a wrapper, explaining its boundaries, and cleaning up conservative output can take more effort than changing those callers directly. Automation has a maintenance cost even when the execution of the tool is convenient. A short, reviewed manual change can be the better engineering choice.
The relevant comparison includes downstream effort. A change that is trivial in one application may be repeated across many independently maintained codebases. Conversely, a widely used package can still have a particular deprecation that is too contextual for safe rewriting. Neither popularity nor a short function body establishes that an automated migration is worthwhile. Start with the shape of the change and the decisions consumers actually face.
There is also a limit to how much a wrapper can teach. It can express a mapping between interfaces, but it cannot explain every business assumption around a call. Keep the rationale in nearby documentation. If maintainers know that a replacement applies only under certain conditions, those conditions should be visible before consumers begin editing. Ambiguous advice becomes more consequential when it accompanies machinery that can spread changes quickly.
For teams commissioning custom software development, migration support is a useful maintenance question to raise while an API is designed. Agree who owns compatibility, which replacements can be expressed mechanically, and which require application judgment. For a simple Go replacement with many consumers, an executable wrapper can be a responsible part of delivery. For a small or semantic migration, ship the clear manual explanation and retain the review.