[hartcw]

Although I don't use go (yet), I can see the benefit of this mechanism as I use a similar one for my own c/c++ code. There I use specially tagged comments to embed python in the c/c++ sources, and then run all the code through a python interpret stage to expand/execute the python code before compiling it. Actually it supports C macro style for the embedded code, which is a bit more sensible than misusing code comments.

For example for generating a c/c++ enum:

    enum example_t
    {
        #py \
        for line in open('values.txt'): \
            print('EXAMPLE_' + line.strip() + ',')
        EXAMPLE_Max,
        EXAMPLE_Unknown
    };

Or alternatively to stuff it in a comment:

    enum example_t
    {
        /* py
        for line in open('values.txt'):
            print('EXAMPLE_' + line.strip() + ',')
        */
        EXAMPLE_Max,
        EXAMPLE_Unknown
    };

If anyones interested, heres the python script I use to preprocess the c/c++ files https://github.com/hartcw/cppy

[threeseed]

Sure the concept is definitely useful. But overloading comments seems monumentally dumb.

They should have copied Java's annotation model which makes a lot more sense.

[copsarebastards]

That's a valid thing to do in C++ because the language doesn't support alternatives. And you can't really expect it to, because C++ has tried various things over the years that make this much harder to add ex-post facto. However, it's worth noting that using such tooling in C++ can cause more problems than it solves if you aren't careful. This is just one of the ways C++ is showing its age.

These problems are exactly why this is unacceptable in Go. Go has the benefit of learning from C++'s mistakes and seeing other attempts at solutions to the problem. Language designers have made these mistakes before, realized they were mistakes, and come up with better alternatives. This is just another example of the Go team either being unaware of or ignoring decades of development in programming languages.

[TheLoneWolfling]

As long as you're making it seem like C / C++ code, but isn't, and will break if you treat it like C / C++ code, why not actually extend the syntax?

Something like PY_CODE(<blah>), for instance. That way it won't compile unless you run it through the preprocessor.

[myg204]

Interesting. Why don't you use an include file directive there?

    enum_example_t
    {
        #include "example_values.txt"
        EXAMPLE_Max,
    } 

where example_values would have the strings 'EXAMPLE_foo,'? Just wondering.