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.

[c410-f3r]

Thank you, @RalfJung and @usbalbin !

[slightlyoutofphase]

Just popping in to say that I just found out that this and const_ptr_write exist and it's like Christmas TBH. The next version I release of my crate staticvec is going to be absolutely nuts thanks to these, with const push, const pop, const insert, and various other things.

One thing I'd ask though is if there are plans to make some_ptr.copy_to(), some_ptr.copy_from() and so on also const-compatible? It seems like there's nothing blocking it, as all of those functions just directly call these intrinsic ones IIRC, and it would be a nice addition on top of this from an ergonomics standpoint.

[RalfJung]

One thing I'd ask though is if there are plans to make some_ptr.copy_to(), some_ptr.copy_from() and so on also const-compatible?

Yeah, those could all easily be made const fn as well, I think.

[usbalbin]

Perhaps something like this #83091

[slightlyoutofphase]

Perhaps something like this #83091

That looks great if it all works! Didn't even think about replace, but I'm pretty sure that would allow me to make even more things const too, actually.

Here's an example snippet taking advantage of what's been implemented so far that I'll be including in the demo program for my crate with the next release, by the way:

// It's also possible to write compile-time initialization functions that suit your specific needs
// with "complex" logic taking advantage of various methods you might typically expect to only
// be available at runtime.
const fn build<T: Copy, const N: usize>(x: [T; N]) -> StaticVec<T, N> {
  // StaticVec implements `Drop`, and so can't *directly* be returned from a `const fn` yet (at
  // least specifically if / when first instantiated as a fully-initialized "naked" function-local
  // variable) even when `T` is `Copy`, making the (sound) use of MaybeUninit below necessary to
  // facilitate regular access to the StaticVec we'll be creating.
  let mut mu = MaybeUninit::new(StaticVec::new());
  // Not actually unsafe here: `sv` is just a mutable reference to a normal empty StaticVec.
  let sv = unsafe { mu.assume_init_mut() };
  // `StaticVec::push` is a `const fn`. Note that loops in `const fn` are limited to `while`
  // currently: if that changes, obviously use an iterator-based `for` loop instead.
  let mut i = 0;
  while i < N {
    sv.push(x[i]);
    i += 1;
  }
  // `StaticVec::pop` is also a `const fn`, so we can do this as well...
  while sv.pop().is_some() {}
  // And put everything back in like this...
  sv.insert_from_slice(0, &x);
  // Still not actually unsafe here: we soundly initialized everything that needed it as soon as we
  // called `StaticVec::new()`.
  unsafe { mu.assume_init() }
  // The methods demonstrated above are by no means the only ones for StaticVec that could be used
  // (and might be useful) in a context like this, so do go ahead and peruse the docs for this crate
  // to find out more.
}

Possibly worth noting that the pop() part of that required adding a feature flag called const_refs_to_cell, which I'd never even heard of. Based on the name of it I'm not sure if that's 100% intentional (as staticvec certainly does not use Cell or even import it), so I figured I'd point it out at least.

[jhpratt]

@RalfJung @oli-obk any blockers here?

[oli-obk]

T-lang approval on #89551 is the blocker that I see. After that, this is purely a libs issue

[jhpratt]

I was presupposing that that is ok'd. Sounds good though.

[Lokathor]

The item that Oli linked was approved and merged. Does this mean we're ready to move forward, or have other blockers come up in the past few months?

[oli-obk]

Nope, a PR assigned to T-libs-api should be uncontroversial now

[m-ou-se]

@rfcbot merge

[rfcbot]

Team member @m-ou-se 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]

Is there anything left here? #97320 should have closed this issue, no?