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

> 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.

It makes those breakages less painful. A project can eventually remove a deprecated API after notifying other projects to run `go fix`. And when projects ignore that advice (some always will), they can revert to a previous working version, run `go fix`, and then upgrade, without spending time in the code identifying how to replace each removed API.

And for those projects that routinely update and run `go fix`, they'll never notice the removal of deprecated code. Given the other benefits of `go fix`, switching to easier to read methods, and leveraging more efficient methods, in addition to security fixes that come with regular updates, this should be the workflow for most maintained projects.

I'm not sure what all of the hazards are, but I could imagine a language (or a policy) where public APIs ship with all of the inline fix directives packaged as robust transactions (some kind of "API-version usage diffs"). When the client pulls the new API version they are required to run the update transaction against their usage as part of the validation process. The catch being that this will only work if the fix is entirely semantically equivalent, which is sometimes hard to guarantee. The benefits would be huge in terms of allowing projects to refine APIs and fix bad design decisions early rather than waiting or never fixing things "because too many people already depend on the current interface".

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.

Because these are instructions for users for making tool-assisted changes to their source code, not a behavior that exists at runtime (or even compile time). A new syntax wouldn't make sense for it.

For other things, like `//go:noinline`, this is fair criticism. `//go:fix inline` is quite different in every way.

The //go:xyz comments are an established pattern in the Go tooling.

I suppose, to minimize its use. If annotations have the same syntactic weight as normal statements, such as “if” or “for” statements, there’s a temptation to use them liberally, which is clearly not a good fit for Go.

By making them comments, Go subtly signals that these are exceptional, making them less prominent and harder to abuse.

I think the core reasoning is about minimizing its use. I have answered [1] the same question in another thread.

https://news.ycombinator.com/item?id=47395574

These are called directives [1], and are treated as metadata by the compiler.

[1] https://pkg.go.dev/go/ast#Directive

This is typical Go design, other languages do it worse, it isn't really needed, and then it gets added half way as it was supposed to be if done early on, and everyone cheers how Go is a "simple" language.

Just like some other famous languages of the authors.

    const x = `This whole thing is
    a
    //go:generate worse-is-better
    multiline
    string literal`

recover()'s semantics make it so that "pointless" use like this can be inlined in a way that changes its semantics, but "correct" use remains unchanged.

Yes, maybe some code uses recover() to check if its being called as a panic handler, and perhaps `go fix` should add a check for this ("error: function to be inlined calls recover()"), but this isn't a particularly common footgun.

Great example, illustrating go1.26.1 go fix source inline transformation breaking program semantics. Raise it as a bug against go fix?

Thanks, that's a bug. We should never inline a function that directly calls recover. I've filed https://go.dev/issue/78193.

Or: your buggy code is no longer buggy.

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

   package main

   type T = [8]byte
   var a T

   //go:fix inline
   func foo() T {
      return T{}
   }

   func main() {
      if foo() == a {
      }
   }

    package main

    //go:fix inline
    func foo[T [8]byte | [4]uint16]() {
        var v T
        var n byte = 1 << len(v) >> len(v)
        if n == 0 {
            println("T is [8]byte")
        } else {
            println("T is [4]uint16]")
        }
    }

    func main() {
        foo[[8]byte]()
    }

Far later submission. Check the ID again.. you were 2 days later.

There was even a more upvoted post between your triple dupe and this https://news.ycombinator.com/item?id=47347322 #scp