enum expects determinant to be isize

[dcampbell24]

const ZERO : i32 = 0;

// OK
#[derive(Copy)]
pub enum A {
    Zero = 0,
}

// Not OK
#[derive(Copy)]
pub enum B {
    Zero = ZERO,
}

pub fn main() {}

<anon>:12:12: 12:16 error: mismatched types:
 expected `isize`,
    found `i32`
(expected isize,
    found i32)
<anon>:12     Zero = ZERO,
                     ^~~~
error: aborting due to previous error
playpen: application terminated with error code 101

[dcampbell24]

My understanding of what is happening in this example is that when zero is passed as 0 the type system infers that it should have type isize and makes is so, but when the number is explicitly given as having some other type, the type system complains because it expected an expression with type isize.

Thus, the discriminant 0 as i32 fails with the same error message, but if the enum is given the attribute #[repr(i32)], then there is no compilation error.

In conclusion, the error message could be improved and I don't understand why if no explicit size for the enum is given, an isize discriminant is expected. This is especially confusing given that the size is actually being chosen by the compiler and could be as small as 1 byte.

[steveklabnik]

/cc @rust-lang/lang

I think the reason here is that integer falllback constraints works for the literal, so I'm not sure this is actually a bug.

but if the enum is given the attribute #[repr(i32)], then there is no compilation error.

This now gives an error

unsupported representation for univariant enum [E0083]

[nrc]

As far as I can see there is no bug here - if you don't specify the type, we infer the right one, if you specify the wrong type, there is a type error. Sounds like we even give a nicer error now.

The only question is should we infer the discriminant type from the literal types, and that sounds like a bad idea to me. Suggest this can be closed.

[nikomatsakis]

So I think it makes sense that the integer value used for the discriminant must have SOME type. We seem to have selected isize unless you tell us another one; this seems like an OK choice. There is an argument for i32 as well, but there isn't much of a difference. This is particularly true since the actual space required by the enum is still a function of the domain of values you use: see e.g. http://is.gd/kQGjNu. So you can always do ZERO as isize to make your code compile (or #[repr(i32)]).

I don't think we can (or should) use the domain of values to pick the required type, since there is kind of a chicken and egg problem. (We have to type the expressions in order to evaluate them, particularly because of overflow semantics, but we can't type them until we know the answers.)

Also: the error message for using a #[repr] on a univariant enum is a bug, but it is #10292.

So I guess my feeling is "not a bug".

[steveklabnik]

Three of us in a row with "not a bug", so I'll close. @dcampbell24 , it's been a long time since you opened this, but let me know if you disagree.