41–50 of 81 posts
Earlier quoted context omitted.
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.
It does not exist in Java. Comments in Java do not change code.
Earlier quoted context omitted.
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.
There are no comment-based directives in Rust, are there?
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") }
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 {
}
}
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.)
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.
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.
Earlier quoted context omitted.
It's an overloaded comment. I am personally quite fine with it, I don't think it's bad. but it is an overloaded comment.
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.
(Though for the record, talking about alternative implementations when discussing Go is kind of a funny joke.)
Earlier quoted context omitted.
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.
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…
Can't golang devs prioritize something like annotations or other attribute/metadata system instead of writing these in comments? I'm pretty sure this must have been raised a lot of times before, so just wanted to ask if there is/are any specific reason(s)?
Can't golang devs prioritize something like annotations or other attribute/metadata system instead of writing these in comments? I'm pretty sure this must have been raised a lot of times before, so just wanted to ask if there is/are any specific reason(s)?
These are called directives [1], and are treated as metadata by the compiler. [1] https://pkg.go.dev/go/ast#Directive