Can't `as` cast Void to usize

[digama0]

enum Void { }
fn void_as_usize(x: Void) -> usize { x as usize } // fails, non-primitive cast

As reported on Zulip: https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/void.20as.20usize

This works for simple enums with one or more variants, but for zero it fails, possibly due to interaction with #[repr(C)]. This kind of code can come up in macro code.

cc @RalfJung

[RalfJung]

I think for zero-variant enums it fails mostly as an oversight. This doesn't even have to generate any MIR as it is unreachable code anyway.

Nominating for lang team discussion.

[digama0]

From the head comment at

rust/src/librustc_typeck/check/cast.rs

Line 10 in 7189ca6

//! * `e` is a C-like enum and `U` is an integer type; *enum-cast*

, I infer that this is indeed only designed to work with C-style enums. My proposal would be to add another cast category saying that empty enums can as cast to anything, desugaring to match x {}.

[RalfJung]

No, enum casts have nothing to do with C-style enums. This works:

pub enum MirPhase {
    Build = 0,
    Const = 1,
    Validated = 2,
}

fn main() {
    let _val = MirPhase::Build as usize;
}

[RalfJung]

Oh, the comment says "C-like". That's not the same as repr(C).
"C-like" just means that all enum variants have no data. This is satisfied by Void -- there are no enum variants, and thus all of them have no data.

[digama0]

Here's the offending check:

rust/src/librustc_middle/ty/mod.rs

Lines 2497 to 2499 in 668ef72

	pub fn is_payloadfree(&self) -> bool {
	!self.variants.is_empty() && self.variants.iter().all(|v| v.fields.is_empty())
	}

It seems that the "payload-free" check is not just "all variants have no data" but also "it is not empty". I would hesitate to change this definition because it's likely to affect C-like enum handling elsewhere, but maybe CastTy can get another class specifically for uninhabited enums.

[RalfJung]

I'd argue a no-variant enum is payload-free. But all uses of that function should be carefully checked.

Adding a new case to CastTy seems like a hack to me.

[scottmcm]

These were historically known as "C-like" enums, and Void is not C-like. From GCC:

<source>:1:12: error: expected unqualified-id at end of input

    1 | enum Void {}

      |            ^

Compiler returned: 1

This kind of code can come up in macro code.

Can you maybe elaborate more on this?

[RalfJung]

Sure, C might not permit them, but I don't see how that's a reason to disallow as casts in Rust.

[tesuji]

I mean, what value does Void as usize have that will make sense?

[Aaron1011]

It's not actually reachable, so it could just typecheck without actually ever needing to produce a value.

[digama0]

@lzutao It can compile the same way as match x {}, which is to say, produce no code and mark the remainder of the function as unreachable. Compiling to 0 would also work for all numeric types that this could target, although then x appears unused which might cause other unintended behaviors in the compiler.

[tesuji]

Currently, the compiler marks match x {} code as error. What do you mean ?

It can compile the same way as match x {}, which is to say, produce no code and mark the remainder of the function as unreachable

Unreachable is unsafe, does it mean that Void as usize is unsafe ?

[digama0]

@lzutao This uses no unsafe code:

enum Void { }
fn void_as_usize(x: Void) -> usize {
    match x {}
}

Here the code after the match statement (if there was any) would be unreachable, and this requires no unsafe code. Basically x is an impossible value, therefore the function cannot be called in the first place and no code need be generated.

EDIT: Your linked example is pattern matching on an i32 with no branches. Here x is an empty enum, Void, so an empty match of an empty enum is exhaustive without any unsafe.