Language designers: stop changing the meanings of words! I know you mean well and you're trying to tie unfamiliar ideas to familiar ones for beginners, but you end up causing more confusion for everyone in the long run.
enum Colour {
Red,
Blue,
Green,
}
is fine. #[derive(Debug)]
enum Colour {
Red = 1,
Blue = 2,
Green = 4,
}
fn main() {
println!("{:?}", Colour::Blue);
println!("{}", Colour::Blue as u8);
}Rust calls them enum to be familiar to people coming from C-family languages, which is a large target.
> since as you noted that term already had a well-established meaning in other languages
Rust enums "degenerate" to a C-style enum (except typesafe) as it can be repr'd to a number and it's possible to select the discriminant (if there's no associated data).
> the concept that Rust calls "enums" also had several existing names (sum type, coproduct type, disjoint union, and, more generally, algebraic data type) in the literature and in prior languages.
Pretty much none of which are actually part of the language e.g. in Haskell or OCaml the designator is `type`, and it's used for both sum types and product types: the sum type simply has a single constructor.
But Rust doesn't use `type`, it uses `struct`. And a `struct` with multiple variants doesn't make sense.
> the sum type simply has a single constructor.
this should be "product" not "sum"
In other languages the concept might correspond to (finite) recursively enumerable sets (ie you can list all their elements).