undefined | Better HN

0 pointsdwattttt10d ago0 comments

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

0 comments

scheme27110d ago

There are directives and packages that affect correctness. E.g. the embed package allows you to initialize a variable using a directive. E.g. //go:embed foo.json followed by var jsonFile string initializes the jsonFile variable with the contents of the foo.json file. A compiler or tooling that doesn't support this results in broken code.

tptacek10d ago

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.

dwatttttOP10d ago

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.

tptacek10d ago

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.

1 more reply

omoikane10d ago

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.

ternaryoperator10d ago

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

9rx10d ago

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

That's why you find it in the comments. That is where tools have found a place to add their own syntax without breaking the Go code.

Absolutely you can do the same in Java. It exists to the exact same degree as it does in Go. I expect it isn't done as often in the Java world because it is much harder to parse Java code so the tools don't get built.

joshuamorton10d ago

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.

1 more reply

Patryk2710d ago

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

win311fwg10d ago

It provides the feature to use. It’s possible nobody has yet.

tptacek10d ago

Eh, you're right, they have a structured attribute system.

joshuamorton10d ago

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

This is not inlining in the compiler. It's a directive to a source transformation (refactoring) tool. So yes, this has no impact on the code. It will do things if you run `go fix` on your codebase, otherwise it won't.

dwatttttOP10d ago

And yet it still breaks "comments aren't semantic". That transformation I described is still invalid.

pastel873910d ago

I don’t understand why that wouldn’t be valid. As far as I understand if you compile code with these go:fix comments, they will be ignored. But if instead of compiling the code you run ‘go fix’, the source code will be modified to inline the function call. Only after the source code has been modified in this way would compiling reflect the inlining. Do you have a different understanding?

1 more reply

j / k navigate · click thread line to collapse

0 comments

scheme27110d ago

tptacek10d ago

dwatttttOP10d ago

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.

tptacek10d ago

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.

1 more reply

omoikane10d ago

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.

ternaryoperator10d ago

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

9rx10d ago

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

That's why you find it in the comments. That is where tools have found a place to add their own syntax without breaking the Go code.

joshuamorton10d ago

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.

1 more reply

Patryk2710d ago

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

win311fwg10d ago

It provides the feature to use. It’s possible nobody has yet.

tptacek10d ago

Eh, you're right, they have a structured attribute system.

joshuamorton10d ago

dwatttttOP10d ago

And yet it still breaks "comments aren't semantic". That transformation I described is still invalid.

pastel873910d ago

1 more reply

j / k navigate · click thread line to collapse