5 ms·

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

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.

joshuamorton 7mo 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.
- dwattttt 7mo ago
  And yet it still breaks "comments aren't semantic". That transformation I described is still invalid.
  - pastel8739 7mo 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?
    - dwattttt 7mo ago
      I mean that directives other than inlining impact correctness. If you have a source file that only builds for one OS, stripping the build tag will break your build.
tptacek 7mo 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.
- ternaryoperator 7mo ago
  It does not exist in Java. Comments in Java do not change code.
  - joshuamorton 7mo 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.
    - TheDong 7mo ago
      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).
      - 9rx 7mo ago
        > Things like "//go:embed" and "//go:build" very much do change the semantics of source code. When you take the source code as a whole they do, but the Go parts are unchanged. The Go spec says nothing about //go:embed, or //go:build. These are not Go features. What you are looking at is another programming language that has been added by a particular tool, using Go comments as the gateway to supporting non-standard syntax inline. > The "//go" comments contain a mix of ones that must be respected to compile That is true, but in using it you've accepted that you are no longer writing Go. In fact, with respect to your talk of C, "Cgo is not Go" is one of the most oft-repeated lines seen in the Go community. It's not just a silly catchphrase. It is the technical reality. Cgo is literally a different programming language, much like how Objective-C is not C despite supporting everything C does.
scheme271 7mo 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.

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

dwattttt 7mo ago
And yet it still breaks "comments aren't semantic". That transformation I described is still invalid.
- pastel8739 7mo 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?
  - dwattttt 7mo ago
    I mean that directives other than inlining impact correctness. If you have a source file that only builds for one OS, stripping the build tag will break your build.

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

ternaryoperator 7mo ago
It does not exist in Java. Comments in Java do not change code.
- joshuamorton 7mo 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.
  - TheDong 7mo ago
    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).
    - 9rx 7mo ago
      > Things like "//go:embed" and "//go:build" very much do change the semantics of source code. When you take the source code as a whole they do, but the Go parts are unchanged. The Go spec says nothing about //go:embed, or //go:build. These are not Go features. What you are looking at is another programming language that has been added by a particular tool, using Go comments as the gateway to supporting non-standard syntax inline. > The "//go" comments contain a mix of ones that must be respected to compile That is true, but in using it you've accepted that you are no longer writing Go. In fact, with respect to your talk of C, "Cgo is not Go" is one of the most oft-repeated lines seen in the Go community. It's not just a silly catchphrase. It is the technical reality. Cgo is literally a different programming language, much like how Objective-C is not C despite supporting everything C does.

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