Tracking Issue for const_maybe_uninit_assume_init

[usbalbin]

Feature gate: #![feature(const_maybe_uninit_assume_init)]

This is a tracking issue for turning the methods assume_init, assume_init_ref, assume_init_mut, slice_assume_init_ref, slice_assume_init_mut of MaybeUninit into const fns. Note that the implementation of the latter two slice related methods are currently behind maybe_uninit_slice #63569, while the constness is behind const_maybe_uninit_assume_init.

Public API

impl<T> MaybeUninit<T> {
    pub const unsafe fn assume_init(self) -> T;
    pub const unsafe fn assume_init_ref(&self) -> &T;
    pub const unsafe fn assume_init_mut(&mut self) -> &mut T;
}

// These function impls are behind `maybe_uninit_slice` while the constnes is `const_maybe_uninit_assume_init` (this issue)
impl<T> MaybeUninit<T> {
    pub const unsafe fn slice_assume_init_ref(slice: &[Self]) -> &[T];
    pub const unsafe fn slice_assume_init_mut(slice: &mut [Self]) -> &mut [T];
}

Steps / History

• Implementation: Constier maybe uninit #79621
• Final comment period (FCP) assume_init and assume_init_ref - Stabilize some MaybeUninit behavior as const #90896
• Stabilization PR for assume_init and assume_init_ref - Stabilize some MaybeUninit behavior as const #90896

Unresolved Questions

• None yet.

[jhpratt]

@RalfJung @oli-obk there should be no issues stabilizing this, correct? I'm going through some things that can be stabilized as const and this seems like it would fall logically from the const union PR that has already been merged.

I was planning to stabilize assume_init and assume_init_ref, as assume_init_mut would be blocked on const mut refs with the two slice methods being unstable in general (the immutable one could have its rustc_const_unstable annotation removed, though).

[oli-obk]

we haven't stabilized transmute yet, all that is blocked on me finishing rust-lang/nomicon#221, then we can start the stabilization wave for unsafe const stuff

[jhpratt]

Was that not #85769?

[oli-obk]

🤦 I am completely lost at the moment on what is stabilized and what is not... I really need to update the skill tree...

Yea, those are trivial to replicate in bad ways on stable then... so we should stabilize them

[jhpratt]

It looks like a number of methods rely on dereferencing a raw pointer or reading one, all of which we don't want at compile-time for the time being due to some uncertainty, correct? If this is permissible, just say so and I can include them.

The one method that can clearly be stabilized without issue is assume_init (with array_assume_init being able to be stabilized with the method itself).

[oli-obk]

We should stabilize raw pointer deref, otherwise ppl will start transmuting raw pointers to references and dereferencing those

[jhpratt]

Just sent Ralf a PM on Zulip asking him to check this out. I recall him having an objection to something of the sort when stabilizing const transmutes — I believe we initially wanted a lint.

[RalfJung]

Yeah there was the idea of having a lint against ptr-to-int transmutes.

My only concern with raw pointers is how and where to document that type-punning loads (i.e., raw-ptr-based transmutes) of pointers to integers are considered UB during CTFE.

[jhpratt]

So raw pointer deref could be stabilized, correct? Dereferencing raw pointers is unsafe to begin with, so documenting that shouldn't be an issue.

[RalfJung]

so documenting that shouldn't be an issue.

Where would you put that documentation though? And would anyone actually read it?^^

But, yeah, just from an implementation perspective I can't think of any reason how raw ptr deref could screw us now that we have stabilized transmutes and union field accesses.

[jhpratt]

I removed bit of my comment that because I realized it was orthogonal to this issue. Sounds good though 👍

[KamilaBorowska]

Is there anything blocking stabilization of const MaybeUninit::assume_init and const MaybeUninit::assume_init_ref at this point?

[jhpratt]

It's in FCP right now!

[KamilaBorowska]

Oh, didn't realize the FCP is going on in #90896.