Tracking Issue for const_ptr_read

[usbalbin]

Feature gate: #![feature(const_ptr_read)]

This is a tracking issue for making the functions ptr::read and ptr::read_unaligned, and the same methods on *const T and *mut T, const fn. This unlocks things like moving values out of arrays in const context.

Public API

mod ptr {
    pub const unsafe fn read<T>(src: *const T) -> T;
    pub const unsafe fn read_unaligned<T>(src: *const T) -> T;
}

impl<T> *const T {
    pub const unsafe fn read(self) -> T;
    pub const unsafe fn read_unaligned(self) -> T;
}

impl<T> *mut T {
    pub const unsafe fn read(self) -> T;
    pub const unsafe fn read_unaligned(self) -> T;
}

Steps / History

• Implementation: Make copy[_nonoverlapping] const #79684
• FCP
• Stabilization PR: Stabilize const_ptr_read #97320

Related

• const_ptr_write Tracking Issue for const_ptr_write #86302

Unresolved Questions

Inorder to make intrinsics::copy and intrinsics::copy_nonoverlapping compile as const fn, some checks were removed.
See comment for some more info

For this PR, I see two options:

• Leave it as "something we can do once we have a story for const-dependent dispatch".
• Comment out the debug assertions for now. Their usefulness is anyway limited since the libstd everyone uses is compiled without debug assertions.

I guess the question is one of evaluating the relative usefulness of these new const operations vs the assertions.

(#79684 did the Comment out the debug assertions for now.-thing).

So the question is, how do we bring them back?

[mbartlett21]

Should this be mentioned in #57563?

[usbalbin]

Perhaps #80697 is a better place to discuss the Comment out the debug assertions for now-question? Since #80697 is specifically for copy[_nonoverlapping]

[c410-f3r]

Are write variants also on the track for "constification"?

• Implementation: Make copy[_nonoverlapping] const #79684

I guess it can be checked now

[RalfJung]

Are write variants also on the track for "constification"?

Let's say they are on the wish list. ;) With #80290, making them const should actually be pretty easy now.

[usbalbin]

Do we need to wait for #80418 (for allowing borrowing) to hit beta before write can be implemented without multiple implementations behind #[cfg(bootstrap)] or is there any other (not too ugly) way? :)

Also intrinsics::forget seems to be not const while mem::forget is const but internally calls ManuallyDrop::new. So how would one best solve that without undoing the "inlining" in #80290?

[RalfJung]

Do we need to wait for #80418 (for allowing borrowing) to hit beta before write can be implemented without multiple implementations behind #[cfg(bootstrap)] or is there any other (not too ugly) way? :)

Well... you could use &mut. 😆
Probably it's better to wait, though.

mem::forget is const but internally calls ManuallyDrop::new

This is supposed to be changed in #79989.