Repository navigation
Closed
Labels
A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)Area: Constant evaluation, covers all const contexts (static, const fn, ...)C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCI-libs-radarLibs issues that are tracked on the team's radar.Libs issues that are tracked on the team's radar.T-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.This issue / PR is in PFCP or FCP with a disposition to merge it.finished-final-comment-periodThe final comment period is finished for this PR / Issue.The final comment period is finished for this PR / Issue.
Description
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?
Reacted by Caio and Trevor Gross
Metadata
Metadata
Assignees
Labels
A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)Area: Constant evaluation, covers all const contexts (static, const fn, ...)C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCI-libs-radarLibs issues that are tracked on the team's radar.Libs issues that are tracked on the team's radar.T-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.This issue / PR is in PFCP or FCP with a disposition to merge it.finished-final-comment-periodThe final comment period is finished for this PR / Issue.The final comment period is finished for this PR / Issue.
Activity
[-]Tracking Issue for XXX[/-][+]Tracking Issue for const_ptr_read[/+]Added reference to tracking issue rust-lang#80377
mbartlett21 commentedon Dec 30, 2020
Should this be mentioned in #57563?
usbalbin commentedon Jan 4, 2021
Perhaps #80697 is a better place to discuss the
Comment out the debug assertions for now-question? Since #80697 is specifically forcopy[_nonoverlapping]c410-f3r commentedon Jan 10, 2021
Are
writevariants also on the track for "constification"?I guess it can be checked now
RalfJung commentedon Jan 18, 2021
Let's say they are on the wish list. ;) With #80290, making them
constshould actually be pretty easy now.usbalbin commentedon Jan 18, 2021
Do we need to wait for #80418 (for allowing borrowing) to hit beta before
writecan be implemented without multiple implementations behind#[cfg(bootstrap)]or is there any other (not too ugly) way? :)Also
intrinsics::forgetseems to be not const whilemem::forgetis const but internally callsManuallyDrop::new. So how would one best solve that without undoing the "inlining" in #80290?RalfJung commentedon Jan 18, 2021
Well... you could use
&mut. 😆Probably it's better to wait, though.
This is supposed to be changed in #79989.
c410-f3r commentedon Jan 19, 2021
Thank you, @RalfJung and @usbalbin !
slightlyoutofphase commentedon Mar 13, 2021
Just popping in to say that I just found out that this and
const_ptr_writeexist and it's like Christmas TBH. The next version I release of my cratestaticvecis going to be absolutely nuts thanks to these, with constpush, constpop, constinsert, 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 commentedon Mar 13, 2021
Yeah, those could all easily be made
const fnas well, I think.11 remaining items
rfcbot commentedon Apr 5, 2023
🔔 This is now entering its final comment period, as per the review above. 🔔
rfcbot commentedon Apr 15, 2023
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.
Rollup merge of rust-lang#97320 - usbalbin:stabilize_const_ptr_read, …
Rollup merge of rust-lang#97320 - usbalbin:stabilize_const_ptr_read, …
RalfJung commentedon Aug 28, 2023
Is there anything left here? #97320 should have closed this issue, no?