Maybe these could even be come kind of code that you can write yourself and define your own pragmas and code transformations by passing some lib folder to the compiler with prebuilt compiler extensions... Ah well.
That's right, if you don't have a newline between the build comment and the package, it gets ignored as a package doc comment, not a build tag. So that comment is treated as a comment, but if there's a newline it isn't.
If we had a normal pragma, "go build" could error out instead, but we don't.
Similarly, if you typo
//go:embd file
go build will ignore that as a comment. If it were '#embd', the tooling could error out with "unrecognized pragma".
I think that's the main argument for not using comments.
#pragma C {
#include <stdio.h>
int foo(var * bar) {
...
}
Or having documentation look like this:
// FIXME: This is kind of a hack, and we should
// get rid of it before v1.0
#pragma docs {
The FooBar function will Foo all the Bars passed to it.
}
func FooBar(...) {
You could even imagine modifying your editor to do proper syntax highlighting on the C code.
Ah, well -- water under the bridge at this point. I like Go as a language overall. Most of their experiments have worked out pretty well, I think; it's inevitable that some of your experiments don't work out the way you expect, and then you're stuck with them.