Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

These should all just have been pragmas with their own syntax. I would even accept something as heretical as "@" for the pragma command, e.g.

  @build linux
  @generate <cmd> <args>
  @C #include <stdio.h>
  @cgo CFLAGS: -etc
  @embed path/to/file
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.


Besides the precious four bytes we would save for each pragma, what's the advantage of using "@" instead of "//go:"?


1. It doesn't look like a comment, so it's less confusing to people new to the language

2. It allows the programmer to skip comments entirely, when reasoning about program behaviour

3. You can write comments without fear of the comment changing program behaviour (probably of little concern in practice, but still)

Putting directives in comments is always a hack. C and C++ get this right, with #pragma.


You also get no completion help from the language server since you are in a damn comment


That's another good point.


These don’t seem like remotely significant issues, especially given how infrequent these directives are.


> 3. You can write comments without fear of the comment changing program behaviour (probably of little concern in practice, but still)

There's historical exceptions, but the new rule is this:

Comments begin with "// ", pragmas don't have that space.


Can you not see how that just amplifies the potential for confusion and bugs?


You get error messages if you get it wrong.

Spot the bug in the below:

    // +build windows
    package my_pkg
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.


Imagine writing cgo like this:

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: