Post History

Your question is a bit ambiguous. Usually when one talks about something being "completely abstract", one means the details of the representation are opaque. This is the sense of "abstract" in "abstract data type". To this end, Rust enums are not "completely abstract" as various details of their representation are exposed and can be further pinned down via [annotations](https://doc.rust-lang.org/stable/reference/type-layout.html#representations).

What I think you're actually asking is whether `Ok`, `Some`, etc. have a run-time representation as opposed to, say, a generic type parameter which gets erased during the compilation process. The answer to this is "yes". (A compiler is always free to optimize out such run-time representation if it can prove the change doesn't affect the program's behavior, but this will be impossible to figure out in general.) Some information needs to be stored so that the code (i.e. the `match` expression) can determine which variant of the type it has. This is especially obvious when considering a type like `Result<T, T>`. `Result<(), ()>` is essentially `bool`.

The most obvious way to implement this &ndash; and almost certainly what `rustc` is doing based on [this description](https://doc.rust-lang.org/reference/types/enum.html) &ndash; is to store a number (the "discriminant" mentioned in that link) to specify which variant of the type you have followed by a representation of that variant. (Again, a sufficiently smart compiler might recognize that types `S` and `T` have disjoint representations and thus `Result<S, T>` would not need a discriminant, but this would be a rare scenario and would add a lot of complexity for little gain.) That said, it's unlikely that any effort is made to distinguish variants in different enum types. In other words, it's very likely that `Ok(3)` and `Some(3)` have the *exact* same run-time representation (particularly if `Ok(3)` is of type `Result<i32, ()>`).

There are other possible representations of enums that could be used, but most of the commonly used alternatives require boxing the types. For example, GHC Haskell stores the discriminant (for enum types with not too many variants) in the pointers to the values. Similarly, one could imagine allocating variants in different parts of the heap so which variant was chosen could be determined based on where the pointer was pointing. Neither of these approaches are applicable to Rust. There aren't a whole lot of other good approaches given the constraints of Rust. (On the other hand, when we consider *arrays* of enum types, there are quite a few possible and useful representations beyond the obvious one.)