5 ms·

I wonder why they chose to add these directives as comments as opposed to adding new syntax for them. It feels like a kludge. https://wiki.c2.com/?HotComments

I wonder why they chose to add these directives as comments as opposed to adding new syntax for them. It feels like a kludge. https://wiki.c2.com/?HotComments https://wiki.c2.com/?HotComments

0x696C6961 7mo ago
The //go:xyz comments are an established pattern in the Go tooling.
- Mond_ 7mo ago
  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.)
  - thwarted 7mo ago
    //go:xyz is dedicated syntax that is compatible with both the language spec and other toolchains that don't know about it.
    - Mond_ 7mo ago
      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.
      - thwarted 7mo ago
        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.
        Mond_ 7mo ago
        Well, I've been unable to follow you as well, then. Obviously if they'd used a different type of syntax (e.g. using # for annotations), those would also be compatible with the language spec, and other implementations would still be just as capable of ignoring all unknown annotations. (Though for the record, talking about alternative implementations when discussing Go is kind of a funny joke.)
        overfeed 7mo ago
        Is gccgo a joke to you?
        debugnik 7mo ago
        Maybe? It's stuck at 1.18 without generics and no one has replaced its maintainer, Ian Lance Taylor, who seems to have moved on after leaving Google. But to be fair to alternative toolchains, TinyGo and TamaGo are also a thing.
        JetSetIlly 7mo ago
        Ian Lance Taylor is in the recent commit history for the main Go implementation. He's not working at Google any more but he's still active.
        debugnik 7mo ago
        I meant gccgo specifically, I don't doubt he's still active with Go in general.
    - deleted 7mo ago
      [deleted]
    - debugnik 7mo ago
      Good luck compiling on a toolchain that doesn't know about //go:embed or /* */import "C" comments.
  - deleted 7mo ago
    [deleted]
kjksf 7mo ago
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.
- bheadmaster 7mo ago
  That's such an elegant solution. I keep being impressed at subtle but meaningful things that Go does right.
  - usrnm 7mo ago
    It only seems right because there are no other implementations and the distinction is meaningless. You don't want to live in the world of multiple slightly different implementations all of which you need to support, this is, roughly, what the C++ build story looks like, and it's not fun.
- dwattttt 7mo ago
  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.
Groxx 7mo ago
Because these are instructions for users for making tool-assisted changes to their source code, not a behavior that exists at runtime (or even compile time). A new syntax wouldn't make sense for it. For other things, like `//go:noinline`, this is fair criticism. `//go:fix inline` is quite different in every way.
piekvorst 7mo ago
I suppose, to minimize its use. If annotations have the same syntactic weight as normal statements, such as “if” or “for” statements, there’s a temptation to use them liberally, which is clearly not a good fit for Go. By making them comments, Go subtly signals that these are exceptional, making them less prominent and harder to abuse.

I wonder why they chose to add these directives as comments as opposed to adding new syntax for them. It feels like a kludge. https://wiki.c2.com/?HotComments https://wiki.c2.com/?HotComments

0x696C6961 7mo ago

The //go:xyz comments are an established pattern in the Go tooling.

Mond_ 7mo ago
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.)
- thwarted 7mo ago
  //go:xyz is dedicated syntax that is compatible with both the language spec and other toolchains that don't know about it.
  - Mond_ 7mo ago
    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.
    - thwarted 7mo ago
      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.
      - Mond_ 7mo ago
        Well, I've been unable to follow you as well, then. Obviously if they'd used a different type of syntax (e.g. using # for annotations), those would also be compatible with the language spec, and other implementations would still be just as capable of ignoring all unknown annotations. (Though for the record, talking about alternative implementations when discussing Go is kind of a funny joke.)
        overfeed 7mo ago
        Is gccgo a joke to you?
        debugnik 7mo ago
        Maybe? It's stuck at 1.18 without generics and no one has replaced its maintainer, Ian Lance Taylor, who seems to have moved on after leaving Google. But to be fair to alternative toolchains, TinyGo and TamaGo are also a thing.
        JetSetIlly 7mo ago
        Ian Lance Taylor is in the recent commit history for the main Go implementation. He's not working at Google any more but he's still active.
        debugnik 7mo ago
        I meant gccgo specifically, I don't doubt he's still active with Go in general.
  - deleted 7mo ago
    [deleted]
  - debugnik 7mo ago
    Good luck compiling on a toolchain that doesn't know about //go:embed or /* */import "C" comments.
- deleted 7mo ago
  [deleted]

kjksf 7mo ago

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.

bheadmaster 7mo ago
That's such an elegant solution. I keep being impressed at subtle but meaningful things that Go does right.
- usrnm 7mo ago
  It only seems right because there are no other implementations and the distinction is meaningless. You don't want to live in the world of multiple slightly different implementations all of which you need to support, this is, roughly, what the C++ build story looks like, and it's not fun.
dwattttt 7mo ago
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.

Groxx 7mo ago

Because these are instructions for users for making tool-assisted changes to their source code, not a behavior that exists at runtime (or even compile time). A new syntax wouldn't make sense for it. For other things, like `//go:noinline`, this is fair criticism. `//go:fix inline` is quite different in every way.

piekvorst 7mo ago

I suppose, to minimize its use. If annotations have the same syntactic weight as normal statements, such as “if” or “for” statements, there’s a temptation to use them liberally, which is clearly not a good fit for Go. By making them comments, Go subtly signals that these are exceptional, making them less prominent and harder to abuse.