3 ms·

You forgot documentation (which actually annoys me more, because I can't put comments to developers of the function right before the function, because it will b

by gwd 6y ago

You forgot documentation (which actually annoys me more, because I can't put comments to developers of the function right before the function, because it will be interpreted as documentation to users of the function). I mean yeah, I think the comment thing is a bit wonky, and it's not the way I'd do it. But once you've got "//go:generate", adding "//go:embed" isn't really any worse. EDIT: Just noticed this line in the proposal: > Another explicit goal is to avoid a language change. To us, embedding static assets seems like a tooling issue, not a language issue. Avoiding a language change also means we avoid the need to update the many tools that process Go code, among them goimports, gopls, and staticcheck. So this partly explains the idea of putting things in comments: things classified as "tooling issues" are put there so that "language tools" aren't affected. I do agree it probably would have been better to invent a specific language construct for, "This is a tooling issue, please ignore"; a bit like the # prefix in C.

masklinn 6y ago
> But once you've got "//go:generate", adding "//go:embed" isn't really any worse. There's way more than that: https://golang.org/src/cmd/compile/internal/gc/lex.go#L53 https://golang.org/src/cmd/compile/internal/gc/lex.go#L53 And I would argue that it's bull. Once they realised that they were introducing pragmas / attributes into the language, they should have bitten the bullet and actually introduced a clean way to annotate language items. The first and second ones are excusable as "we'll only need one" and "well it's not worth the hassle" but at the third one it's not a special case it's a pattern. Especially as the excuse that "other implementations can ignore those" gets less and less true: a compiler which ignores go:embed can not be considered working.
- xpressvideoz 6y ago
  Wow, the lexer function is even named "pragmaValue". So Go does have a concept of pragma, not just magic comments. Go developers' stubbornness on forward compatibility is beyond me.
  - bojanz 6y ago
    To quote[1] Russ Cox: "C uses #pragma foo for this. Go simply spells #pragma as //go:." https://www.reddit.com/r/golang/comments/hv96ny/qa_goembed_draft_design/fywm1ap/ https://www.reddit.com/r/golang/comments/hv96ny/qa_goembed_d...

by gwd 6y ago

masklinn 6y ago

> But once you've got "//go:generate", adding "//go:embed" isn't really any worse. There's way more than that: https://golang.org/src/cmd/compile/internal/gc/lex.go#L53 https://golang.org/src/cmd/compile/internal/gc/lex.go#L53 And I would argue that it's bull. Once they realised that they were introducing pragmas / attributes into the language, they should have bitten the bullet and actually introduced a clean way to annotate language items. The first and second ones are excusable as "we'll only need one" and "well it's not worth the hassle" but at the third one it's not a special case it's a pattern. Especially as the excuse that "other implementations can ignore those" gets less and less true: a compiler which ignores go:embed can not be considered working.

xpressvideoz 6y ago
Wow, the lexer function is even named "pragmaValue". So Go does have a concept of pragma, not just magic comments. Go developers' stubbornness on forward compatibility is beyond me.
- bojanz 6y ago
  To quote[1] Russ Cox: "C uses #pragma foo for this. Go simply spells #pragma as //go:." https://www.reddit.com/r/golang/comments/hv96ny/qa_goembed_draft_design/fywm1ap/ https://www.reddit.com/r/golang/comments/hv96ny/qa_goembed_d...