[Merkur]

I too like the idea that comments are more than blabber. I do use comments like //BUG: //TODO: and //HOT:

My argument is semantic? Yes it is! In my optinion thats the reason my argument is so strong.

Please dont tell me you dont see a problem between //go: foor and //todo: bar - the first instructing some tool to change stuff in your build, the later merly mention that there is something left to do here.

A directive like #todo: bar - is a great example for a great tool in the chain. the go tool could look for a "todo" command and this todo command could print out a warning that the code should not be released because XX todos arn't done. If the go tool would'nt find a "todo" command it could warn me that a tool in the chain is missing. I could evaluate in decide to use get this tool, or choose to ignore it.

This would be imposible if comments are missused as directives!

[fixxer]

Now argue against yourself and prove you understand why you hit resistance.

[Merkur]

if you can agree that i got arguments that convince - i do you the favor. :)

[fixxer]

I agree that you have raised an argument. I haven't read anything to indicate you understand the issue at a higher level. It would definitely help me respect your argument as sincere if you argued the counter with sophistication.

[Merkur]

okay, i'll jump :)

1) First of all change is not nessesary - because within the current "comment directive convention" the tooling needs can be achived. Even more so - they can be achived without changing the current spec of the language.

2) As I learned during this discussion there are "comment directive convention" that are older as go 1.4. I could imaging they play a role deep inside the go tooling. i.e. I could imaging that the cgo stuff has some deep roots. It would some work to change all occurences - that is glass clear - because even now there are legacy directives // +build //link that are not updated to the "new convention" //go: foo

3) I dont know about the internal mechanism that the go team needs to observce to change the spec of a language, that is perhaps in wide productive use within the google. But i can imagin there is procedure. Changing the spec meight just not be possible before Go 2.0 because of policy.

4) It meight not be desired to introduce something that smells like a macro language into the code. There meight be some animosity againt it - give the clean code philosopy that Go aimes for.

No, i dont realy believe that. I am Sorry to have accused! On contrary: The yacc tool gives great power to expand the language. But yacc is a heavy lifting tool and not something like a macro every one could use. Its also not part of the spec, just given as magic comment - no prommise made.

5) One counter argument that is invalid: I am pretty sure the go team cares about semantic. :-) All programmers do breath semantic. Of course there are different tastes.

6) You basicly cant prevent magic... in comments or otherwise its the reason its called magic.

7) those commented directives can stay in all levels of the build process - without adaptions of the spec. This means tools have the potential to hook on source, on ast, etc.

[fixxer]

1, 2, and 4 are pretty strong arguments.

I've written a handful of go generate utilities to do everything from CRUD boilerplate to produce Python clients. Generally, I have found the current approach simple enough and don't have any motivation to change. I would like to see more definition in terms of best practices as defined by the core authors (perhaps release a few more of those internal tools). They have done a little to try to coax the community into their way of thinking, but I think we need more. Coming from C/C++, your motives aren't unreasonable, but I also fear the innovation might encourage sprawl well beyond the original concept definition. That restraint is pretty common in the history of the language and a way of thinking that I like.

As with so many that desire generics, maybe the solution is simpler: Go might not be the right language for you.

[0xdeadbeefbabe]

> One counter argument that is invalid: I am pretty sure the go team cares about semantic. :-) All programmers do breath semantic. Of course there are different tastes.

I put up with whatever semantics are necessary to get the CPU to do the right thing, but I'm more excited about CPUs than semantics.

[Merkur]

well, i see - my statement was flawed. :)