Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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?

+6
−0

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?

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

1 answer

+6
−0

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.)

History
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »