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.
//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.
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.
I keep being impressed at subtle but meaningful things that Go does right.
For other things, like `//go:noinline`, this is fair criticism. `//go:fix inline` is quite different in every way.
(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.)
By making them comments, Go subtly signals that these are exceptional, making them less prominent and harder to abuse.
Just like some other famous languages of the authors.
const x = `This whole thing is
a
//go:generate worse-is-better
multiline
string literal`
package main
//go:fix inline
func handle() {
recover()
}
func foo() {
handle()
}
func main() {
defer foo()
panic("bye")
}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.
This is an impossible task. For a library function, you can't know whether or not the function is defer called.
Maybe this is not an important problem. But it would be better if the blog article mentions this.
It is just a demo.
package main
import "unsafe"
//go:fix inline
func foo[T any]() {
var t T
_ = 1 / unsafe.Sizeof(t)
}
func main() {
foo[struct{}]()
}
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]()
}There was even a more upvoted post between your triple dupe and this https://news.ycombinator.com/item?id=47347322 #scp
These //go.* commands always remind me of this:
"""
//GO.SYSIN DD *
DOO DAH
DOO DAH
"""
(Why yes, that is IBM System 360 JCL from circa 1975. Why do you ask?)