| |
| ▲ | alecthomas 4 hours ago | parent [-] | | Someone else said this below... > Go designers distinguish between Go language as defined by Go spec and implementation details.
> //go:fix is something understood by a particular implementation of Go. Another implementation could implement Go without implementing support for //go:fix and it would be a fully compliant implementation of Go, the language.
>
> If they made it part of the syntax, that would require other implementations to implement it. ...I'm not sure I buy that argument TBH. | | |
| ▲ | freakynit 4 hours ago | parent [-] | | hmm... thanks... And yes, I don't buy it either. "If they made it part of the syntax, that would require other implementations to implement it." ... I mean, so what? Has golang stopped ading new features to the spec? If not (which I guess so), then how is this any different? Unless you have freezed the language, this reasoning doesn't make sense to me. | | |
| ▲ | 9rx an hour ago | parent [-] | | You are right that there could be new syntax, like, say, `@tool:name args` or `#tool.name args`, but is that any different than `//tool:name args`? They all read the same to me. The upside of that particular syntax is that only the parser used by tools needs to understand directives. All other parser implementations can be blissfully unaware, negating the need for special no-ops. The downside is...? | | |
| ▲ | freakynit 43 minutes ago | parent [-] | | I mean, technically you could write your entire business logic inside comments and have some tool parse it successfully. But we don't do that, because intuitively we know that's not the right place for it. The issue isn't that this approach is incorrect, it's that it feels out of place. A comment should be a comment, nothing more. When comments start carrying executable meaning or structured directives, they stop serving their primary purpose. It also becomes difficult to represent anything moderately complex in a clear way. Once the structure grows beyond something trivial, readability suffers quickly. To me, it ends up feeling like command-line arguments.. technically workable, but messy and hard to reason about. Just look at something like "ffmpeg" arguments.. and then compare that to defining the same configuration through a structured format like Yaml or Json. The latter is simply clearer and easier to maintain. It's not wrong, but, it doesn't feel right. | | |
| ▲ | 9rx 29 minutes ago | parent [-] | | > I mean, technically you could write your entire business logic inside comments and have some tool parse it successfully. It sounds like you are talking about cgo. I think you have a stronger case there, but it is much the same situation: It's conceptually a third-party add-on that the Go language doesn't know anything about. "Cgo is not Go"[1] I mean, if you really did have your own business logic language that you needed to include in Go code, where else would you put it if not in the "comments"? You, a random third-party, won't be able to add syntax to Go, so you cannot reasonably consider that to be an option. What syntax could Go add that is flexible enough to allow anyone to add anything they need, but that doesn't end up being comments by another token? > A comment should be a comment, nothing more. It's not really a comment, though. It is a directive. A comment is structured like `// Who the hell wrote this crap?`, while this is structured like `//tool:name args`. I think what you are saying is that you don't like overloaded syntax, which is fair, but Go overloads syntax in several places so this is not a unique case. Besides, most languages end up with overloaded syntax in practice, so it isn't even something unique to Go. [1] https://go-proverbs.github.io |
|
|
|
|
|
