[HN Gopher] //go:fix inline and the source-level inliner
___________________________________________________________________
//go:fix inline and the source-level inliner
Author : commotionfever
Score : 82 points
Date : 2026-03-11 18:39 UTC (4 days ago)
(HTM) web link (go.dev)
(TXT) w3m dump (go.dev)
| measurablefunc wrote:
| https://en.wikipedia.org/wiki/Hygienic_macro
| tapirl wrote:
| It looks the following code will be rewritten badly, but no ways
| to avoid it? If this is true, maybe the blog article should
| mention this. package main
| //go:fix inline func handle() { recover()
| } func foo() { handle() }
| func main() { defer foo() panic("bye")
| }
| arccy wrote:
| Or: your buggy code is no longer buggy.
| tapirl wrote:
| You claim listens right for this specified example. :D
|
| It is just a demo.
| shoo wrote:
| Great example, illustrating go1.26.1 go fix source inline
| transformation breaking program semantics. Raise it as a bug
| against go fix?
| tapirl wrote:
| As I have mentioned, no ways to fix it. Because it is hard to
| know whether or not the handle function is called in a
| deferred call.
| tapirl wrote:
| Another example (fixable): package main
| import "unsafe" //go:fix inline func foo[T
| any]() { var t T _ = 1 /
| unsafe.Sizeof(t) } func main() {
| foo[struct{}]() }
|
| Go is a language full of details: https://go101.org/details-
| and-tips/101.html
| shoo wrote:
| If I follow, this isn't a compile time inline directive, it's a
| `go fix` time source transformation of client code calling the
| annotated function.
|
| Per the post, it sounds like this is most effective in closed-
| ecosystem internal monorepo-like contexts where an organisation
| has control over every instance of client code & can `go fix` all
| of the call sites to completely eradicate all usage of a
| deprecated APIs:
|
| > For many years now, our Google colleagues on the teams
| supporting Java, Kotlin, and C++ have been using source-level
| inliner tools like this. To date, these tools have eliminated
| millions of calls to deprecated functions in Google's code base.
| Users simply add the directives, and wait. During the night,
| robots quietly prepare, test, and submit batches of code changes
| across a monorepo of billions of lines of code. If all goes well,
| by the morning the old code is no longer in use and can be safely
| deleted. Go's inliner is a relative newcomer, but it has already
| been used to prepare more than 18,000 changelists to Google's
| monorepo.
|
| It could still have some incremental benefit for public APIs
| where client code is not under centralised control, but would not
| allow deprecated APIs to be removed without breakage.
| avabuildsdata wrote:
| yeah this is the part that got me excited honestly. we're not
| google-scale by any stretch but we have ~8 internal Go modules
| and deprecating old helper functions is always this awkward
| dance of "please update your imports" in slack for weeks. even
| if it doesn't let you delete the function immediately for
| external consumers, having the tooling nudge internal callers
| toward the replacement automatically is huge. way better than
| grep + manual PRs
| shoo wrote:
| it could be better than a nudge -- if you could get a
| mandatory `go fix` call into internal teams' CI pipelines
| that either fixes in place (perhaps risky) or fails the build
| if code isn't already identical to fixed code.
| omoikane wrote:
| I wonder why they chose to add these directives as comments as
| opposed to adding new syntax for them. It feels like a kludge.
|
| https://wiki.c2.com/?HotComments
| 0x696C6961 wrote:
| The //go:xyz comments are an established pattern in the Go
| tooling.
| Mond_ wrote:
| This is begging the question. Yes, but _why_ did they do that
| over dedicated syntax?
|
| (My personal theory is that early go had a somewhat misguided
| idea of simplicity, and preferred overloading existing
| concepts with special cases over introducing new keywords.
| Capitalization for visibility is another example of that.)
| thwarted wrote:
| //go:xyz _is_ dedicated syntax that is compatible with both
| the language spec _and_ other toolchains that don 't know
| about it.
| kjksf wrote:
| Go designers distinguish between Go language as defined by Go
| spec and implementation details.
|
| //go:fix is something understood by a particular implementation
| of Go. Another implementation could implement Go without
| implementing support for //go:fix and it would be a fully
| compliant implementation of Go, the language.
|
| If they made it part of the syntax, that would require other
| implementations to implement it.
| bheadmaster wrote:
| That's such an elegant solution.
|
| I keep being impressed at subtle but meaningful things that
| Go does right.
| dwattttt wrote:
| If the comments impact correctness (which inlining doesn't,
| but I believe there are other directives that do), saying
| it's "an implementation detail" waves away "it's an
| implementation detail that everyone needs" aka part of the
| spec.
|
| The reason it feels like a kludge is that "comments" are
| normally understood to be non-impactful. Is a source
| transformation that removes all comments valid? If comments
| have no impact per the spec, yes. But that's not the case
| here.
|
| In practice comments in go are defined to be able to carry
| semantic meaning extensibly. Whether they're safe to ignore
| depends on what meaning is given to the directives, e.g.
| conditional compilation directives.
| joshuamorton wrote:
| > The reason it feels like a kludge is that "comments" are
| normally understood to be non-impactful. Is a source
| transformation that removes all comments valid? If comments
| have no impact per the spec, yes. But that's not the case
| here.
|
| This is not inlining in the compiler. It's a directive to a
| source transformation (refactoring) tool. So yes, this has
| no impact on the code. It will do things if you run `go
| fix` on your codebase, otherwise it won't.
| dwattttt wrote:
| And yet it still breaks "comments aren't semantic". That
| transformation I described is still invalid.
| tptacek wrote:
| There's nothing unique to Go about this kind of tooling. It
| exists in C, Java, Rust, Typescript, and probably dozens of
| other settings as well. It's the standard way of
| implementing "after-market" opt-in directives.
| ansgri wrote:
| Good illustration that a seemingly simple feature could require a
| ton of functionality under the hood. Would be nice to have this
| in Python.
___________________________________________________________________
(page generated 2026-03-15 23:00 UTC)