also, I feel strong about getting rid of cancer, should I write a treatise about the importance of getting rid of cancer since you may consider that not very important too?
One off the top of my head that I run into all the time is in client stubs of service APIs, where a client-side enum representing a string value will break at runtime if the service adds a new string value.
In other words, enums inhibit API evolution.
I've done a fair amount of Go programming in large teams, mostly doing distributed systems stuff, and I've never run into a situation where I was like "Damn I wish I had enums here." Strings have worked just fine, and we've never had any bugs related to that. I have, however, run into situations where I was like "Wow, good thing I wasn't using an enum here." And in some of our Java code, we've had multiple production issues caused by over-eager devs using enums everywhere. They implicitly enforce a contract on the value of the data, which can be quite undesirable if they don't actually care about the contract (e.g. they're just passing values through to something else).
The Go compiler should be technically capable of doing that without breaking iota or introducing a new feature. Have you considered raising a request for it if one doesn't already exist?
Go’s compiler toolchain does not “warn” users by design: only hard errors.
In fact, the varcheck checker in gometalinter probably even covers this use case: https://github.com/alecthomas/gometalinter/blob/master/READM...
enum foo {Bar, Baz, Foobar};
void f() {
enum foo f = 5; // Will happily compile
int f2 = Baz; // Will happily compile
}
type foo int
const (
bar foo = iota
baz
foobar
)
func f() {
var f foo = 5 // Will happily compile, i.e as bad as C-tier enums
var f2 int = baz // error: cannot use baz (type foo) as type int in assignment
}In every other language, people keep arguing about advanced features, moving forward and such, only in Go people defend the undefendable and reject any kind of the simplest obvious improvements, I say so and I am sad because I use Golang very heavily, it's sad to see a modern language so popular and its core designers are still stubborn about doing anything in the right direction even if it is as simple as adding enums
Readability-wise, this is disputable, the go version is a bit more verbose, but I can't imagine a developer not understanding what happens there at first sight.
I didn't know that enums are so controversial, unnecessary and equivalent to just constants, but maybe a look of how it's done in any other language can give you a clear difference between enums and constants
https://doc.rust-lang.org/1.30.0/book/2018-edition/ch06-01-d...
https://doc.rust-lang.org/rust-by-example/custom_types/enum....
Thing is, as soon as you provide users with one more feature, some of these users want even more features: "yeah, enums are great, but I would like to have type safety with them; oh, type safety is important, but why not have sum types, after all? Oh, now that we have sum types, why not add pattern-matching?"
All of these features are great, but they make the language harder to master, and tooling harder to write. This is a tradeoff, there are many languages that implement all the features its users want (I can think of C++, Rust, probably C# too), why not let other language designers try another way?
I have to admit I wouldn't dislike an enum construct in Go, just syntactic sugar that would be equivalent to the type foo int + const block, but I certainly won't push for it.
But I'm sure someone on the Go team will see your witty comment and rethink their approach entirely.
The argument is that the programming language should have the good features. Maybe that's an unwise stance, but it doesn't seem to be the one you're arguing against.