4 ms·
Instead of an ad hominem, please clearly explain the main way that the example Go code is less safe than the C example code.
by DblPlusUngood 8y ago
Instead of an ad hominem, please clearly explain the main way that the example Go code is less safe than the C example code.
- the_other_guy 8y agoI didn't mean the C example to be applied in C compilers, I meant having the first example in Golang itself, enums are not just constants, they are type safe constants, you can't just use any other constants in some switch-case and get away with it, that's the raison d'etre of enums in the first place 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-defining-an-enum.html 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.html https://doc.rust-lang.org/rust-by-example/custom_types/enum....
- the_other_guy 8y agoI am being downvoted without a single counter argument, typical HN
- sacado2 8y agoYou first asked for C-style enums, which are not type safe constants (but nothing more than integer constants), then asked for type-safe constants, and then, you say they are not enough either and you want full-blown rust-style enums, which are not enumeration types but true sum types. 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.