[nicerobot]

Just because _you_ are locked into a mentality about a meaning for // does not mean we all are. Explain to me why formatted/structured text can not appear after a // in a file. If your editor parsed the text and formatted it to look meaningful, like code, would that help?

[Merkur]

Yes, I like to elaborate. Good code is unambiguous.

IF has a meaning - and it always have this meaning. FUNC has a meaning - always the same. // are comments. The meaning of comments is to communicate with humans.

We know the principal of "overloading" syntax. Things can have a different meaning in a different context. One could argue using //go: is overloading the comment. BUT: Go is not a language that do's overloading - in fact its philosophy is against overloading, as it is against generics. (and I realy like this philosophy!)

I argue that directives to the tool chain should not apear in a comment - because a directive to the tool chain has a different & incompatible meaning than a comment.

I argue future: There is a need for directives to the tool chain in the Go source code. The go-team has this need, and there can be great things done with such e mechanism. The go community will do great things with directives! I see tons of use cases for godep. I see tons of use cases for debuggers, profilers and all kinds of other tools.

The go-team not only implements go, they also set an example to the usage of the language. If they misuse comments to express directives, other projects will eventualy follow.

But what will happens in the long run if we embrace that example and use //foo: bar as directives for our tool chains?

The go tool chain could not generate meaningfull errors about missing tools, or syntax errors in directives. Also: Comments would not be safe to communicate with fellow programmers - who knows that kind of tools where used in my dependencies? And what kinds of //foo: should be marked pink in my editor? All of em?

All this could be solved by using an other syntax for directives. I do not care if its # or @ or #! or whatever - as long as it is not a comment.

I also have no argument about macros, generics or whatever. I just want go to be unambiguous.

[henesy]

I'm not sure why it bothers everyone so much. I might be missing something, but unless people are writing their comments in a very specific style then it shouldn't cause issues. From the help: "(note: no leading spaces and no space in "//go") where command is the generator to be run, corresponding to an executable file that can be run locally." It just seems like the code is distinctive enough it shouldn't cause problems. Or, if style should be adjusted, why not write your "not code" comments using the /* */ style?

[stefantalpalaru]

What part of "all syntax should be validated" don't you understand? By putting that syntax in comments, syntax errors will not trigger any output from the tools because they remain valid free-form comments.

[henesy]

And they're not "Go" syntax. The syntax in the comments if for Go tools. A better approach may be to provide a more extensive syntax checking tool that parses comments and checks for syntax errors on a per-tool basis, but as I understand it it would seem that the implementation as it is now is aimed at the auxiliary Go tools, standardizing the syntax for the tools, thus allocating potential for future tools to expand without extensive maintenance on the core language itself. The tools are not the core language, but there should probably be some form of syntax checkers for the tools, but perhaps encapsulated within the tools. The comments are still comments to the actual Go code, as they are not pertinent to the language itself, but rather an outside entity such as a tool. It is also entirely possible that I am missing the point entirely and do not understand.

[stefantalpalaru]

It's irrelevant which tool does the checking. The problem is that you don't know whether "// go:generate foo", "//ho:generate bar" or "//go;generate baz" are errors or simply comments.

In order to detect most of that you'll have to redefine the comment syntax for the core language so it's no longer free-form but anything that looks like a comment-directive now triggers a warning (or most likely an error seeing the Go philosophy).