Rust: Tracking Issue for const `mem::discriminant`

Created on 8 Mar 2020  路  5Comments  路  Source: rust-lang/rust

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

Implemented in #69825

A-const-fn B-unstable C-tracking-issue Libs-Small Libs-Tracked T-lang T-libs

Most helpful comment

@lcnr we already have that with things like

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

All 5 comments

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.

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?

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.

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];

@lcnr we already have that with things like

const ARR: [u32; mem::size_of::<Option<Option<bool>>> = [42];
Was this page helpful?
0 / 5 - 0 ratings