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.

Also 'cgo' comments which are fairly old. See: 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/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.

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

If the add "//Todo:" as syntax, many projects would be screwed. Abusing comments for anything else is not good.

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

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.

And there's

    //line path/to/file:linenumber

and

    //go:noescape

Reminds me of typescript

/// <reference path="../typings/tsd.d.ts" />

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

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.

don't forget

    //go:nosplit

too

And go:linkname, go:nointerface, and go:nowritebarrier You can see the lexer for these here: https://github.com/golang/go/blob/88c08b06b97296e41fc3069f4a...