Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Are generic enums completely abstract?
When using Result or Option to get a value, the value is wrapped in a Ok or Some. For example, with pattern matching to get a Result:
let var: Json = match serde_json::from_str(&my_string) {
Ok(a) => a,
Err(e) => return e,
};
Will there be any representation of the Ok, Err, Some, or None in the machine code of the compiled program, or are they completely abstract mechanisms within the language?
1 answer
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.
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 – and almost certainly what rustc is doing based on this description – 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.)
0 comment threads
0 comment threads