51–57 of 57 posts
https://pkg.go.dev/structs@master
What more sane languages would use attributes for, Go 1.23 will do it like this,
type myStruct struct {
_ struct.HostLayout
}
Earlier quoted context omitted.
> I am not a huge fan of go:generate and similar projects. They add a level of unknown that goes against the core Golang design values. I'm not sure I would agree with that. go:generate is a core part of Go since v1.4 and the enum generators are the kind of thing that was intended. https://go.dev/blog/generate That said, enums would be a welcome improvement to the language. But even then, I think go:generate has a pl…
"add(ing) a level of unknown" is a very fair description from a code comprehensibility standpoint, since the go:generate directive is about running arbitrary executables.
Earlier quoted context omitted.
Only if you remember, which you, or someone else, is bound to not eventually
But you're not adding variants without a reason? You want them to have some effect. It's hard for me to think of an example where it would make even sense to "having to remember to handle the variant" rather than "handling the desired effect of the variant".
The problem isn't so much the lack of enums, it's more that there is no way to do exhaustive pattern matching at compile time. I have seen production systems go down because someone added a variant to an 'enum' but failed to handle that new variant everywhere.
There are two linters that add those checks: https://github.com/nishanths/exhaustive for values and https://github.com/alecthomas/go-check-sumtype for types. Both are integrated into golangci-lint. I use both a lot and have only a positive experience. Having support from the language would be nice, though.
The problem isn't so much the lack of enums, it's more that there is no way to do exhaustive pattern matching at compile time. I have seen production systems go down because someone added a variant to an 'enum' but failed to handle that new variant everywhere.
Isn’t that the first thing you would do if you add a new variant?
Use a slice of strings? type Color int const ( Red Color = iota Green Blue ) var Colors = []string{ "Red", "Green", "Blue" } Now (Colors[Red] == "Red") and (slices.Index(Colors, "Green") == Green).
Compile-time safety is not achieved which is the point.
There is no language that completely isolates you from runtime hazards.
Enums in Go are not good. Code generation just makes it worse. Both because code generation has a bad smell and because nobody can agree on how to do enums in Go so we just end up with lots of diverging solutions. Go 2 needs to have more usable enums. And while I'm not a big fan of "adding more stuff" to languages, it wouldn't hurt Go to learn a couple of things from Rust.
I can't see why they wouldn't be in a future 1.x release
I'm not a language design expert, but I suspect there be worms in that there can.