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

Post by TheDong » Mon, Mar 16, 2026, 4:40 AM UTC

joshuamorton wrote: post #41

ternaryoperator wrote: post #31

Earlier quoted context omitted.

It does not exist in Java. Comments in Java do not change code.

This also does not change th code. It is an advertisement to a linter-loke tool to take some action on the source code. Its most similar to linter directives which usually are comments.

Post by freakynit » Mon, Mar 16, 2026, 5:00 AM UTC

alecthomas wrote: post #51

freakynit wrote: post #50

Earlier quoted context omitted.

Understood... but why in comments?

Someone else said this below... > 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…

Post by hrmtst93837 » Mon, Mar 16, 2026, 6:02 AM UTC

arjvik wrote: post #23

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

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.

Post by overfeed » Mon, Mar 16, 2026, 6:09 AM UTC

Mond_ wrote: post #46

thwarted wrote: post #30

Earlier quoted context omitted.

I'm no longer sure what you're saying. You asked why they didn't go with dedicated syntax, I listed two advantageous aspects of the chosen syntax. We know it's an overloaded comment: that's literally one of the advantages.

Well, I've been unable to follow you as well, then. Obviously if they'd used a different type of syntax (e.g. using # for annotations), those would also be compatible with the language spec, and other implementations would still be just as capable of ignoring all unknown annotations. (Though for the record, talking about alternative implementations when discussing Go is kind of a funny joke.)

Post by freakynit » Mon, Mar 16, 2026, 7:56 AM UTC

9rx wrote: post #59

freakynit wrote: post #54

Earlier quoted context omitted.

hmm... thanks... And yes, I don't buy it either. "If they made it part of the syntax, that would require other implementations to implement it." ... I mean, so what? Has golang stopped ading new features to the spec? If not (which I guess so), then how is this any different? Unless you have freezed the language, this reasoning doesn't make sense to me.

You are right that there could be new syntax, like, say, `@tool:name args` or `#tool.name args`, but is that any different than `//tool:name args`? They all read the same to me. The upside of that particular syntax is that only the parser used by tools needs to understand directives. All other parser implementations can be blissfully unaware, negating the need for special no-ops. The downside is...?