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.

[tesuji]

Thanks, I got that part now. But the question raised by Scott still remain: What is the concrete example of macros that have use cases for Void as usize ?

Also, Void is a never type, if Void is usize allowed, would we want to make any operations on Void unreachable?

[digama0]

The actual macro where this came up was a safe wrapper that declares an int-like enum and an array indexed by the enum. Roughly, it creates a type enum Foo { User, Defined } and struct FooVec<T>([T; Foo::LEN]), and then the Index<Foo> implementation for FooVec uses vec.0[i as usize] where i: Foo. When Foo has zero elements, this causes the macro to produce malformed code.

It is possible to work around this issue by explicitly checking for this case, but I don't really see a reason for it not to work in the first place.

would we want to make any operations on Void unreachable?

Any operation on Void is unreachable. That means that the compiler can do whatever it wants to for codegen here because it doesn't matter, the function is not callable. But from a typing point of view, I think that (x: Foo) as usize should have type usize, not !.

[RalfJung]

It's no surprise that macros run into this -- this happens any time that we have special exceptions. "enums without fields can be cast to integers, except if the enum has 0 variants" is such a special exception, and from a language design perspective it has no reason to exist.

Not sure what the next step here is -- probably an RFC? This is a language extension after all.

[nikomatsakis]

Discussed in the @rust-lang/lang meeting today:

• We agreed that this seems like a harmless extension (specifically: permitting zero variant enums to be as to a usize).
• We don't feel an RFC is required and we would recommend somebody creating a PR that fixes this and nominates the PR for lang-team consideration, we can do an FCP directly on the PR.

[Mark-Simulacrum]

I have opened #76199 to fix this issue.