Tracking Issue for const_ptr_read · Issue #80377 · rust-lang/rust (original) (raw)

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(src: *const T) -> T; pub const unsafe fn read_unaligned(src: *const T) -> T; }

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

impl *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?