4 ms·

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

by Asooka 6y ago

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.

yiyus 6y ago
Besides the precious four bytes we would save for each pragma, what's the advantage of using "@" instead of "//go:"?
- MaxBarraclough 6y ago
  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.
  - throwaway894345 6y ago
    These don’t seem like remotely significant issues, especially given how infrequent these directives are.
  - yencabulator 6y ago
    > 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.
    - breakingcups 6y ago
      Can you not see how that just amplifies the potential for confusion and bugs?
  - saturn_vk 6y ago
    You also get no completion help from the language server since you are in a damn comment
    - MaxBarraclough 6y ago
      That's another good point.
- TheDong 6y ago
  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.
gwd 6y ago
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.

by Asooka 6y ago

yiyus 6y ago

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

MaxBarraclough 6y ago
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.
- throwaway894345 6y ago
  These don’t seem like remotely significant issues, especially given how infrequent these directives are.
- yencabulator 6y ago
  > 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.
  - breakingcups 6y ago
    Can you not see how that just amplifies the potential for confusion and bugs?
- saturn_vk 6y ago
  You also get no completion help from the language server since you are in a damn comment
  - MaxBarraclough 6y ago
    That's another good point.
TheDong 6y ago
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.

gwd 6y ago

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.