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
• Stabilize some MaybeUninit behavior as const #90896 (assume_init and assume_init_ref)

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.

[workingjubilee]

We have the option of const-stabilizing assume_init_mut: #86722

[dtolnay]

@rfcbot fcp merge

assume_init and assume_init_ref were const-stabilized already by #90896.

This FCP proposes const-stabilizing assume_init_mut, which has been unblocked by #129195.

Further, it proposes moving the const-stability of slice_assume_init_ref and slice_assume_init_mut, which are still unstable, out of this tracking issue over to those functions' main tracking issue, and this one can be closed. When or if these functions get stabilized in the future, they can be const-stabilized at the same time.

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[RalfJung]

@workingjubilee is there a reason this is not part of your big const stabilization PR?
It doesn't seem to have an open PR at all right now.

[workingjubilee]

@RalfJung No reason, I think! Slipped through the cracks because I am merely mortal.

[workingjubilee]

Oh, I think I missed this because I looked for features, when stabilizing things, with actual issue numbers in the code... this thing had never gotten its correct issue number assigned in the code.

[RalfJung]

Oh lol this had issue = "none"? I guess someone forgot to note down the tracking issue.^^

Thanks for making a PR!