Change:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: This is a tracking issue for turning the methods , , , , of into s. Note that the implementation of the latter two slice related methods are currently behind , while the constness is behind . <!-- Include a short description of the feature. --<!-- For most library features, it'd be useful to include a summarized version of the public API. (E.g. just the public function signatures without their doc comments or implementation.) --<!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] Implementation: [x] ( and ) <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final comment period (FCP) is always needed before stabilization. This works as follows: A library API team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final comment period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
there should be no issues stabilizing this, correct? I'm going through some things that can be stabilized as and this seems like it would fall logically from the const union PR that has already been merged. I was planning to stabilize and , as would be blocked on const mut refs with the two slice methods being unstable in general (the immutable one could have its annotation removed, though).
we haven't stabilized transmute yet, all that is blocked on me finishing , then we can start the stabilization wave for unsafe const stuff
Was that not rust-lang/rust?
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
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 (with being able to be stabilized with the method itself).
We should stabilize raw pointer deref, otherwise ppl will start transmuting raw pointers to references and dereferencing those
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.
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.
So raw pointer deref could be stabilized, correct? Dereferencing raw pointers is to begin with, 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.
I removed bit of my comment that because I realized it was orthogonal to this issue. Sounds good though :+1:
Is there anything blocking stabilization of and at this point?
It's in FCP right now!
Oh, didn't realize the FCP is going on in
We have the option of const-stabilizing :
fcp merge and were const-stabilized already by This FCP proposes const-stabilizing , which has been unblocked by Further, it proposes moving the const-stability of and , 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.
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [ ] 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 for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , 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.
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.
No reason, I think! Slipped through the cracks because I am merely mortal.
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.
Oh lol this had ? I guess someone forgot to note down the tracking issue.^^ Thanks for making a PR!

Discussion:
#![feature(const_ipv6)] #![feature(const_likely)] #![feature(const_make_ascii)] <del> #![feature(const_maybe_uninit_assume_init)] </del> #![feature(const_nonnull_new)] #![feature(const_num_midpoint)] #![feature(const_option)]

/// }; /// ``` #[stable(feature = "maybe_uninit_ref", since = "1.55.0")] <del> #[rustc_const_unstable(feature = "const_maybe_uninit_assume_init", issue = "none")] </del> <ins> #[cfg_attr(bootstrap, rustc_allow_const_fn_unstable(const_mut_refs))] #[rustc_const_stable( feature = "const_maybe_uninit_assume_init", since = "CURRENT_RUSTC_VERSION" )] </ins> #[inline(always)] pub const unsafe fn assume_init_mut(&mut self) -> &mut T { // SAFETY: the caller must guarantee that `self` is initialized.

/// /// [`assume_init_mut`]: MaybeUninit::assume_init_mut #[unstable(feature = "maybe_uninit_slice", issue = "63569")] <del> #[rustc_const_unstable(feature = "const_maybe_uninit_assume_init", issue = "none")] </del> <ins> #[cfg_attr(bootstrap, rustc_allow_const_fn_unstable(const_mut_refs))] #[rustc_const_unstable(feature = "maybe_uninit_slice", issue = "63569")] </ins> #[inline(always)] pub const unsafe fn slice_assume_init_mut(slice: &mut [Self]) -> &mut [T] { // SAFETY: similar to safety notes for `slice_get_ref`, but we have a