Rather than the tagged union which the word represents in Rust, and only Rust. Java's enums are close, since they're classes and one can add arbitrary behaviors and extra data associated with the enum.
Very well then: Rust is not the only one to call a variant type / tagged union an enum. It's a nice language feature to have, whatever they decide to call it.
It remains a strange choice to refer to this as the true enum, actual enum, real enum, as has started occurring since Rust became prominent. If that's a meaningful concept, it means a set of numeric values which may be referred to by name. This is the original definition and remains the most popular.
Rust is targeting both users who know the original definition as well as people who don’t. Differentiating between real enums and sum types means the language gets another keyword for a concept that overlaps.
From a PL theory perspective, enum denotes an enumerable set of values within a type. It just happens that sums slot in well enough with that.
Checked the definition. An enum is defined as a set of named constants. Id argue that a set by definition needs to be constrained. If it lacks the constraints/grouping id argue it no longer is a set.
> While I have no particular beef with Rust deciding to call its sum types "enum", to refer to this as the actual enum is a bit much.
I didn't read GP as saying "Actual enums are what Rust has", I read it more as "Go doesn't have actual enums", where "enum" is a type that is constrained to a specified set of values, which is what all mainstream non-Rust languages with enums call "Enums".
I mean, even if Rust never existed, the assertion "Go doesn't have actual enums" is still true, no?
That's an interpretation I hadn't considered, mostly because Borgo has Rust-style tagged unions which it also calls enums. The statement wouldn't have caught my attention if I'd read it in that light, but while I'm here, I don't mind opining.
"Does Go have enumerated values" seems much like "does Lua have objects". Lua doesn't have `class` or anything like it, it has tables, metatables, and metamethods. But it makes it very easy to use those primitives to create a class and instance pattern, including single inheritance if desired, and it even offers special syntax for defining and calling methods with `:` and `self`. If I had to deliver a verdict, I would say that the special syntax pushes it over the line, and so yeah: with some caveats, Lua has objects.
Same basic thing with Go. One may define a custom integer type, and a set of consts using that type with `iota`, to get something which behaves like plain old small-integer enums. It's possible to undermine this, however, by defining more values of this type, which makes this pattern weaker than it could be, but in a way which is similar to the enums found in C.
Ultimately, Go provides iota, and making enums is the intended purpose of it. If you search for "enums in Go" you'll find many sources describing an identical pattern. So, like `self` and `:` in Lua, I'd say that `iota` in Go means that it has an enumerated type.
But if someone wanted to say "Go doesn't even have enums, you have to roll your own, other languages have an enum keyword", I have a different opinion than that first clause, but there's nothing factually wrong with any of it. I find this sort of "where's the threshold" question less interesting than most.
Enumerated types are simply named integers in most languages, exactly the sort you get with const / iota in Go: https://en.wikipedia.org/wiki/Enumerated_type
Rather than the tagged union which the word represents in Rust, and only Rust. Java's enums are close, since they're classes and one can add arbitrary behaviors and extra data associated with the enum.