-
Notifications
You must be signed in to change notification settings - Fork 13k
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
default representation for enum discriminant should be i32 #24290
Comments
triage: P-backcompat-lang (1.0) |
Not happening for 1.0. Hopefully can be done backwards-compatibly later. |
Triage: old issue. Lot's has happened around enums since. @rust-lang/lang what do? |
cc @durka |
@eddyb checked into this; we currently choose the repr based on the value range, so we're closing as resolved. |
It... doesn't look like this was ever actually fixed? enum En {
V1 = 0xFFFF_FFFF_FFFF_FFFF,
} which gives this warning on x86_64:
|
Spawned off of #24270.
Rust has attempted to support a semantics for enum discriminant representation where, if you did not choose an explicit enum representation, it would infer the appropriate representation to use.
This seems fine as long as one hides that representation from the user, but with intrinsics like
discriminant_value
, it becomes a bit problematic, since e.g. it is hard to know what type to use when comparing elements of theenum
. (You need to cast it to the right type so that you do not e.g. mistake-1
for a large postiive value.)Plus, it turns out that we don't actually do all that much inference at all; a simple experiment like this:
when run with a 32-bit target, reveals that the const-evaluator is only using
isize
for the type anyway, and will not automatically promote toi64
.So, after discussing (irc) the matter with @nikomatsakis I think we change things slightly so that at the language level, in terms of what the const-eval does etc, we should just use
i32
. (Of course, if you override the choice with#[repr(...)]
, then we will use that instead.)This would be a breaking change for 64-bit platforms, but arguably what it is really doing is fixing a portability bug that has laid dormant for at least a little while (and perhaps a long while -- its a long story).
The text was updated successfully, but these errors were encountered: