-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docs somewhat unclear regarding C-like enum discriminators #17770
Comments
No, in C they are defined to start with 0 by default. Saying that the representation is undefined in C is also wrong because every implementation defines the representation. Enums in Rust also have to follow the C behavior to make FFI less error prone. |
So, would it be correct to say that enum representation in C is "implementation-dependent"?
So Rust's C-like enums are guaranteed to start with 0. And this is true regardless of what |
Because I suck at reading specs, Twitter helped: https://twitter.com/jckarter/status/554769119438848000 and that's true:
Also:
and
So yeah. We should have this in the docs. |
We now have this text, search for "Enums have a discriminant. ". |
internal: Remove AbsPathBuf::TryFrom impl that checks too many things at once rust-lang/rust-analyzer#16889 (comment)
The reference states pretty clearly that the memory layout of
struct
s is undefined by default, and presumably the same thing can be said of complex enum variants.However, for C-like enums (simple enums which correspond to some integer type), it doesn't seem to be clear whether implicit discriminators are well defined. One resource (no longer in the actual docs, it seems) says that they are well defined (starts with 0, increases by 1 for each variant). But I couldn't find any other docs that comment on this (the reference does state that an enum with
#[repr(C)]
will have the default C ABI enum size - but also that enum representation in C is undefined? Is that referring to the implicit discriminators?).In essence, can we assume that implicit discriminators start with 0 and increase by 1 per variant, or is this never an assumption we can make?
The text was updated successfully, but these errors were encountered: