//go:fix inline and the source-level inliner

Post by kjksf » Sun, Mar 15, 2026, 9:59 PM UTC

omoikane wrote: post #7

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

Post by bheadmaster » Sun, Mar 15, 2026, 10:01 PM UTC

kjksf wrote: post #11

omoikane wrote: post #7

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

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.

Post by tapirl » Sun, Mar 15, 2026, 10:06 PM UTC

tapirl wrote: post #3

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") }

    package main

    import "unsafe"

    //go:fix inline
    func foo[T any]() {
        var t T
        _ = 1 / unsafe.Sizeof(t)
    }

    func main() {
        foo[struct{}]()
    }

Post by thwarted » Sun, Mar 15, 2026, 10:08 PM UTC

Mond_ wrote: post #12

0x696C6961 wrote: post #8

Earlier quoted context omitted.

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

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

Post by shoo » Sun, Mar 15, 2026, 10:23 PM UTC

avabuildsdata wrote: post #14

shoo wrote: post #4

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 m…

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 be…