default representation for enum discriminant should be i32

[pnkfelix]

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 the enum. (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:

enum E {
    A = 0,
    B = 0xF_FFFF_FFFF,
}

fn main() { }

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 to i64.

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

[pnkfelix]

triage: P-backcompat-lang (1.0)

[brson]

Not happening for 1.0. Hopefully can be done backwards-compatibly later.

[brson]

Triage: old issue. Lot's has happened around enums since. @rust-lang/lang what do?

[aturon]

cc @durka