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.

▲

dwattttt 10 hours ago | parent | next [-]

Are we referring to 'go fix' as after market tooling?

It's certainly done in many places. JsDoc is the biggest example I can think of. But they're all walking the line of "this doesn't have an impact, except when it does".

It being done by the language owners just makes them the ones walking the line.

▲

tptacek 10 hours ago | parent [-]

That's exactly how this works: it doesn't have an impact, except when you ask it to. This is an idiomatic approach to this problem.

▲

dwattttt 9 hours ago | parent [-]

The part I object to is overloading comments, which aren't meant to be load bearing. A tool developed outside the language has no choice but to take something that has no meaning and overload it, but language owners weren't forced to take this route; they could've made directives not comments.

In practice, the Go language developers carved syntax out of comments, so that a comment is "anything that starts with //, unless the next characters are go:"

	▲	YesThatTom2 8 hours ago \| parent [-]
		So how many angels can you fit on the head of a pin?

▲

omoikane 9 hours ago | parent | prev | next [-]

In the listed examples, the compiler will emit a diagnostic upon encountering those comments:

https://go.dev/blog/inliner#example-fixing-api-design-flaws

So these comments carry more weight than how those comment annotations might be consumed by optional tools for other languages.

For most of the listed examples, I think the corresponding C annotation would have been "[[deprecated]]", which has been added to the syntax as of C23.

▲

ternaryoperator 9 hours ago | parent | prev | next [-]

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

▲

9rx 5 minutes ago | parent | next [-]

It doesn't exist in Go either. https://go.dev/ref/spec

That's why you find it in the comments. That is where third-party tools can add their own syntax without breaking Go code.

Absolutely you can do the same in Java. I expect it isn't done as often in the Java world because it is much harder to parse Java code.

▲

joshuamorton 8 hours ago | parent | prev [-]

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.

	▲	TheDong 4 hours ago \| parent [-]
		We're talking about the "//go" comments in general I think here. Things like "//go:embed" and "//go:build" very much do change the semantics of source code. The comments above 'import "C"' containing C function definitions and imports change the compilation of go source code. The "//go" comments contain a mix of ones that must be respected to compile, to being optional, to being entirely ignorable (like generate and fix).

▲

Patryk27 9 hours ago | parent | prev [-]

There are no comment-based directives in Rust, are there?

	▲	win311fwg 8 hours ago \| parent \| next [-]
		It provides the feature to use. It’s possible nobody has yet.
	▲	tptacek 9 hours ago \| parent \| prev [-]
		Eh, you're right, they have a structured attribute system.