4 ms·
Besides the precious four bytes we would save for each pragma, what's the advantage of using "@" instead of "//go:"?
by 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 ago1. 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 agoThese 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 agoCan you not see how that just amplifies the potential for confusion and bugs?
- saturn_vk 6y agoYou also get no completion help from the language server since you are in a damn comment
- MaxBarraclough 6y agoThat's another good point.
- TheDong 6y agoYou 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.