Sorry, but you're not right, at least in the way that Rust uses the terms "enum" and "tuple." In Rust, an enum is a sum type (also called a "discriminated union" in some other languages; we don't use this term for Reasons), and a tuple is a product type (like arrays). Result is an enum.

Oh interesting - I had no idea that Rust called such a thing enum. Wanting to avoid the term discriminated union makes a lot of sense - the untagged union (what you'd get in C for instance) is a train wreck in that it is not a full statement of data. It's pretty hard to talk about tagged unions without people shortening it to unions - there are some alternatives out there like sum type, but I haven't seen them gain much traction linguistically. Within untagged unions the type is generally constrained to a certain extent by compiler checks but the true type of the value is always unknown unless communicated by a separate piece of data. Usually good uses of unions occur in places where that second piece of data is carried along side the first piece (tuple style) in a struct - generally the type should be inferrable from some piece of related data unless you want some serious headaches.

It's all good! Yeah, Rust has C-style unions as well, though they're unsafe, and largely for C interop.

Rust's enums give you the full power of putting other data structures inside of them; the variants can hold data of any kind; single values, structs, tuples, and even other enums.

Coming from C/C++, "enums with data" sound more interesting to me than "unions with a type", even though they describe the same thing. I used C/C++ enums far more often than unions, and often wished I could add extra data to them.

Another thing is that adding data to Rust enums is optional, and so you can have an enum of variants with no data. The union equivalent to that would be a type-only union which sounds kind of odd.