4 ms·

(You left out "// +build", which predates Go 1.4.) We made the decision that "//go:" is the syntax for comment directives. The old ones stay around for compati

• TheDong 11y ago
  Also 'cgo' comments which are fairly old. See: https://golang.org/cmd/cgo/ https://golang.org/cmd/cgo/ For an example of what this looks like in actual use, see the very popular go-sqlite3 library: https://github.com/mattn/go-sqlite3/blob/dee1a37fe11067e97971fac64fa5bff4ef0934f4/sqlite3.go#L8 https://github.com/mattn/go-sqlite3/blob/dee1a37fe11067e9797... I personally think that large block-comments of code that actually do something, but only if above a certain import really strange and unexpected; it means re-ordering imports can break things, changing around spacing can break things, and tons of other things.
• eis 11y ago
  If this has to reside in comments, will the old directives be updated with aliases for the new convention? So the old ones can be kept around for backwards compatibility (maybe with a warning) but codebases could still be updated to be consistent. All of these of course are minor things. Go does a lot of things very right like easy of concurrency, scope and quality of the standard library and easy of deployment. Looking forward to the GC improvements in the near future as well as a day when we get generics. I'll be a happy camper then.
• vorg 11y ago
  And there's //line path/to/file:linenumber and //go:noescape
  • ominous_prime 11y ago
    don't forget //go:nosplit too
    • scottpiper 11y ago
      And go:linkname, go:nointerface, and go:nowritebarrier You can see the lexer for these here: https://github.com/golang/go/blob/88c08b06b97296e41fc3069f4afbc86d24707b05/src/cmd/internal/gc/lex.go#L1552 https://github.com/golang/go/blob/88c08b06b97296e41fc3069f4a...
  • mattkrea 11y ago
    Reminds me of typescript /// <reference path="../typings/tsd.d.ts" />
    • kevingadd 11y ago
      /// is metadata/docstrings - it's a convention from C#. So a /// block is parsed by the compiler and tooling (to generate documentation xml files, for example), while a // comment is not parsed at all, just stripped.
      • mattkrea 11y ago
        Gotcha. Although most of the guys I see use the /// <summary> stuff as comments in the real world I guess I can see the difference.
• Merkur 11y ago
  I think this was a bad decision. I think you would agree as soon a tool emerges that follows your example and uses //todo: bar to do stuff with the code, and makes the program fail because it's not done, because you don't know about it. with a #todo: bar the go tool chain would catch this error
  • castell 11y ago
    If the add "//Todo:" as syntax, many projects would be screwed. Abusing comments for anything else is not good.
    • JadeNB 11y ago
      Maybe I have missed the point, but your post sounds like you think Merkur disagrees. I think that you are actually agreeing with the GP (https://news.ycombinator.com/item?id=9523335 https://news.ycombinator.com/item?id=9523335), which says that: > I think this was a bad decision. I think you would agree as soon [as] a tool ... uses > //todo: bar (i.e., that the `//todo:` syntax would unambiguously demonstrate the bad-ness of the decision).
• antimagic 11y ago
  The issue that I, and apparently many other people, have is that this is just an unnecessary potential confusion. Why not use another symbol for directives, instead of overloading comments? Why create the potential for confusion - not everyone that will work with Go is going to be deep in the ecosystem - for example they might be using an editor that mischaracterises the line as a comment. Why create this potential for confusion instead of just using a new symbol ($$, @@, %%, whatever). It would be much clearer to the casual reader that this is something that will have an impact at the tool level.