> I haven’t seen a single programming language that has decent enums.
There's not much you can do with an enumeration. It's just something that counts one-by-one.
A useful tool when you have a large set of constants that you want to number, without having to manually sit there 0, 1, 2, 3... But that's the extent of what it can offer.
> With that I mean fundamental and fool proof functions for to/from a string, to/from an int, exhaustive switch cases, pattern matching, enumerating.
While a programming language may expose this kind of functionality, none of these are properties of enums. They are completely separate features. Which you recognize, given that you are able to refer to them by name. Calling these enums is like calling if statements functions because if statements may be layered with functions.
Can someone help me understand why enums are needed? They only seem like sugar for reducing a few lines while writing. What cannot be achieved without them or what is really a pain point they solve? Maybe it is hard to have a constant with type information?
It does not. You'll notice that if you read through your link. A tag-only union is not the same thing, even if you can find some passing similarities.
If you mean it has enums like the Democratic People's Republic of Korea has a democracy, then sure, it does have enums in that sense. I'm not sure that gives us anything meaningful, though.
If we're being honest, sum types are the better solution. Enums are hack for type systems that are too limited for anything else. They are not a feature you would add if you already have a sufficient type system. It's not clear why Rust even wants to associate itself with the hack that are enums, but your link shows that its author has a fundamental misunderstanding of what enums even are, so it may be down to that.
To be fair, Swift made the same mistake, but later acknowledged it. It is interesting that Rust has chosen to double down instead.
Enums produce values. Tag-only unions 'produce' types (without values).
Realistically, there isn't a whole lot of practical difference. They were both created to try and solve much the same problem. As before, I posit that there is no need for a language to have both. You can do math on enum values, but that is of dubious benefit. In theory, tag-only unions provide type safety, whereas enums are just values so there is no inherit safety... But, as you probably immediately recognized a few comments back, with some static analysis you can take the greater view,
type E int
const (
A E = iota
B
C
)
and invent something that is just as useful as proper type safety. All the information you need is there. So, in reality, that need not even be significant.
But, technically there is a difference. Values and types are not the same thing.
With that I mean fundamental and fool proof functions for to/from a string, to/from an int, exhaustive switch cases, pattern matching, enumerating.
Seems like something that wouldn’t be too hard but everybody always fails on something.