Tracking Issue for const `mem::discriminant`

[lcnr]

The feature gate for the issue is #![feature(const_discriminant)].

History

• Implementation: make mem::discriminant const #69825
• Stabilization PR: Const stabilize mem::discriminant #116240

Unresolved issues

• Interpreter calls discriminant_for_variant on zero variant enum #89765 ICE when used on zero variant enums

[RalfJung]

The intrinsic is already implemented in Miri, you can copy that to rustc if you want.

If you do, please also submit a PR to Miri to remove the implementation there.

[oli-obk]

Should we consider adding more symbol kinds to const eval (like the way pointers can't be read as bits) to ensure that this feature isn't used to read discriminants as integers? Or is doing so at compile time actually something that enables legit use cases?

[RalfJung]

What we do for pointers is born out of necessity, and causes pain throughout the engine.

For discriminants (a) I cannot think of a practical way to do so, and (b) I view this the same as layout details: it is not UB to use raw pointers to observe and mess with repr(Rust) layout if you get it right, but layout might change any time so you have no way to be sure that whatever is right for current Rust will remain right in the future.

[lcnr]

Would this be to prevent something like this (which may break due to compiler updates)?

#![feature(core_intrinsics, const_discriminant)]

const ARR: [u32; std::intrinsics::discriminant_value(&Some(7)) as usize] = [42];

[RalfJung]

@lcnr we already have that with things like

const ARR: [u32; mem::size_of::<Option<Option<bool>>> = [42];