What are semantics of empty enums that have been artificially fabricated?

[brson]

Updated bug report follows (see bottom for original bug report)

This bug appears to have been filed in error but then spawned a very interesting conversation.

The question centers around how empty enums (e.g. enum Foo { }, which has zero variants) which in principle cannot safely exist, interact with our casting operations (namely safe as and unsafecast::transmute).

Here is an some code that I wrote that summarizes the various scenarios that were described in the comments. Most of the scenarios do not compile (which is good). The fifth, sixth, and seventh all compile; their runtime behaviors vary, but most are acceptable. The only questionable thing @pnkfelix can see here is the behavior for the seventh example, cfg ex7.
Code:

#[allow(dead_code)];
use std::cast;
enum Foo { }
struct Bar;

#[cfg(ex1)]
fn main() {
    let i = Foo as int;
    println!("i: {:?}", i);
}

#[cfg(ex2)]
fn main() {
    fn f(f: Foo) -> int { f as int }
}

#[cfg(ex3)]
fn main() {
    let i : Foo = unsafe { cast::transmute(3) };
    println!("i: {:?}", i);
}

#[cfg(ex4)]
fn main() {
    let b : Bar = Bar;
    let i : Foo = b as Foo;
    println!("b: {:?}", b);
    println!("i: {:?}", i);
}

#[cfg(ex5)]
fn main() {
    let b : Bar = Bar;
    let i : Foo = unsafe { cast::transmute(b) };
    println!("b: {:?}", b);
    println!("i: {:?}", i);
}

#[cfg(ex6)]
fn main() {
    let b : Bar = Bar;
    let i : Foo = unsafe { cast::transmute(b) };
    println!("b: {:?}", b);
    match i {
    }
}

#[cfg(ex7)]
fn main() {
    let b : Bar = Bar;
    let i : Foo = unsafe { cast::transmute(b) };
    println!("b: {:?}", b);
    match i {
        _ => { println!("The impossible!"); }
    }
}

Transcript of compile (+ runs when compilable):

% rustc --cfg ex1 /tmp/ee.rs && ./ee
/tmp/ee.rs:8:13: 8:16 error: unresolved name `Foo`.
/tmp/ee.rs:8     let i = Foo as int;
                         ^~~
error: aborting due to previous error
% rustc --cfg ex2 /tmp/ee.rs && ./ee
/tmp/ee.rs:14:27: 14:35 error: non-scalar cast: `Foo` as `int`
/tmp/ee.rs:14     fn f(f: Foo) -> int { f as int }
                                        ^~~~~~~~
error: aborting due to previous error
% rustc --cfg ex3 /tmp/ee.rs && ./ee
/tmp/ee.rs:1:1: 1:1 error: transmute called on types with different sizes: int (64 bits) to Foo (0 bits)
/tmp/ee.rs:1 #[allow(dead_code)];
             ^
% rustc --cfg ex4 /tmp/ee.rs && ./ee
/tmp/ee.rs:26:19: 26:27 error: non-scalar cast: `Bar` as `Foo`
/tmp/ee.rs:26     let i : Foo = b as Foo;
                                ^~~~~~~~
error: aborting due to previous error
% rustc --cfg ex5 /tmp/ee.rs && ./ee
b: Bar
task '<main>' failed at 'enum value matched no variant', /Users/fklock/Dev/Mozilla/rust.git/src/libstd/repr.rs:559
% rustc --cfg ex6 /tmp/ee.rs && ./ee
b: Bar
task '<main>' failed at 'scrutinizing value that can't exist', /tmp/ee.rs:44
% rustc --cfg ex7 /tmp/ee.rs && ./ee
b: Bar
The impossible!
% 

Original bug report follows:

Something like this works:

enum Foo { }

let i = Foo as int;

Doesn't make any sense.

[catamorphism]

I don't think this actually does work? Foo is a type, not a term; the second line of code there errors out because Foo isn't in the value namespace.

Since it's impossible to construct a value of type Foo here, there's no problem as far as I can tell -- if you can construct a value of type Foo, then you can cast it to int. False implies anything. But maybe I'm misunderstanding?

[brson]

Oh, you are right. My example is bogus and doesn't demonstrate the problem. Take this one:

enum Foo { }
fn f(f: Foo) -> int { f as int }

Of course this code can never be run (without unsafe) since Foo can't be constructed. The cast though is allowed even though we know it is bogus. It almost certainly represents a logic error that could be reported.

But there are a lot of other similar things we could catch, like using match with a zero-variant enum and the line must be drawn somewhere.

[catamorphism]

Huh, now I'm morbidly wondering what happens if you cast something to Foo in an unsafe block.

I'm not really sure what error we should report here, tbh. I'd be fine with disallowing uninhabited types, but they do have their uses. If we make a conscious decision to allow uninhabited types, then it doesn't seem principled to forbid doing perfectly sound things with them. After all, if someone is using uninhabited types, they are probably up to some monkey business that we can't usefully second-guess.

[nikomatsakis]

I think we should have a policy that uninhabited types are fine, but if we encounter a place where we can't sensibly codegen because the type is uninhabited, we generate a fail. An example would be matching an empty enum.

This case is borderline to me because being C-like (and hence castable to uint) is not a property that all enums share, so we can choose to say that empty enums do not have this property if we like. However, it also seems reasonable to say "C-like enums are those for which all variants have arguments", in which case empty variants qualify. In that case, I'd say that 'foo as uint' should fail, since there is no sensible way to codegen it.

[catamorphism]

That's what we already do for matching on an empty enum -- fail with "the impossible happened" or something like that.

[nikomatsakis]

right, that's what I thought we did

[catamorphism]

This is really a language spec question. Nominating for milestone 1.

[graydon]

consensus is "this should be an error", accepted for backwards compatibility

[bblum]

The only thing you can cast to an empty enum is another 0-size struct, so attempting anything else will give a transmute called on types with different sizes error.

This test case fails with enum value matched no variant:

use std::cast;
use std::io;
enum Void { }
struct Foo;
fn main() {
    let x: Void = unsafe { cast::transmute(Foo) };
    io::println(fmt!("%?", x));
}

I also can't seem to cast an empty enum to anything. The compiler says non-scalar cast: Voidasuint``. So I'd say this isn't an issue.

However, maybe we could also make the type-size of empty enums something other than 0, so even the above transmute attempt fails? Would that make sense, or would it mess up e.g. cases where you have a void inside a struct?

[thestinger]

Triage bump.

[pnkfelix]

(maybe we should hide empty Enums under a feature flag for 1.0?)

[nikomatsakis]

On Thu, Sep 26, 2013 at 10:53:58AM -0700, Felix S Klock II wrote:

(maybe we should hide empty Enums under a feature flag for 1.0?)

No! Let's just decide and settle this. It is... really not important.
I vote for "whatever the behavior is now, it's fine." :)

[pnkfelix]

@nikomatsakis its more that there are other things that seem ... questionable with empty enums.

Like case of struct X in the examples I added to the description for Issue #2634

[flaper87]

visiting for triage

@nikomatsakis @pnkfelix @brson what's the final take here?

[pnkfelix]

@flaper87 I'm inclined at this point to go with @nikomatsakis and say that behavior now, as described by @bblum in the above comment is fine.

There may be other oddities with empty enums (like #2634), but as it stands this bug is kind of bogus: According to a survey I just did of the examples provided in the description and comments, only bblum's comment seems to reflect the current state of affairs, and his example does not describe a bug per se, but rather just shows how you can currently use transmute to get an instance of an empty enum (but only by feeding it another empty struct).

I'm going to update the description to reflect this state of things. And then I'm going to close the bug.