Repository navigation
Tracking Issue for const_maybe_uninit_assume_init #86722
Description
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
MaybeUninitbehavior as const #90896 (assume_initandassume_init_ref)
Unresolved Questions
- None yet.
Reacted by Felipe S. S. Schneider
Activity
jhpratt commentedon Sep 28, 2021
@RalfJung @oli-obk there should be no issues stabilizing this, correct? I'm going through some things that can be stabilized as
constand this seems like it would fall logically from the const union PR that has already been merged.I was planning to stabilize
assume_initandassume_init_ref, asassume_init_mutwould be blocked on const mut refs with the two slice methods being unstable in general (the immutable one could have itsrustc_const_unstableannotation removed, though).oli-obk commentedon Sep 28, 2021
we haven't stabilized transmute yet, all that is blocked on me finishing https://github.com/rust-lang/nomicon/pull/221, then we can start the stabilization wave for unsafe const stuff
jhpratt commentedon Sep 28, 2021
Was that not rust-lang/rust#85769?
oli-obk commentedon Sep 28, 2021
🤦 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 commentedon Sep 29, 2021
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(witharray_assume_initbeing able to be stabilized with the method itself).oli-obk commentedon Sep 29, 2021
We should stabilize raw pointer deref, otherwise ppl will start transmuting raw pointers to references and dereferencing those
jhpratt commentedon Sep 29, 2021
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 commentedon Sep 30, 2021
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 commentedon Sep 30, 2021
So raw pointer deref could be stabilized, correct? Dereferencing raw pointers is
unsafeto begin with, so documenting that shouldn't be an issue.RalfJung commentedon Sep 30, 2021
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 commentedon Sep 30, 2021
I removed bit of my comment that because I realized it was orthogonal to this issue. Sounds good though 👍
sugar700 commentedon Nov 22, 2021
Is there anything blocking stabilization of
const MaybeUninit::assume_initandconst MaybeUninit::assume_init_refat this point?jhpratt commentedon Nov 22, 2021
It's in FCP right now!
13 remaining items
rfcbot commentedon Oct 4, 2024
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 commentedon Oct 4, 2024
@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 commentedon Oct 5, 2024
@RalfJung No reason, I think! Slipped through the cracks because I am merely mortal.
workingjubilee commentedon Oct 5, 2024
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 commentedon Oct 5, 2024
Oh lol this had
issue = "none"? I guess someone forgot to note down the tracking issue.^^Thanks for making a PR!
Rollup merge of rust-lang#131274 - workingjubilee:stabilize-the-one-t…
Rollup merge of rust-lang#131274 - workingjubilee:stabilize-the-one-t…
Unrolled build for rust-lang#131274
Rollup merge of #131274 - workingjubilee:stabilize-the-one-that-got-a…
Rollup merge of rust-lang#131713 - tgross35:stabilize-const_maybe_uni…
Unrolled build for rust-lang#131713
Rollup merge of rust-lang#131713 - tgross35:stabilize-const_maybe_uni…