-
Notifications
You must be signed in to change notification settings - Fork 13.6k
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 RFCLibs-TrackedLibs issues that are tracked on the team's project board.Libs issues that are tracked on the team's project board.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.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?
c410-f3r and tgross35
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 RFCLibs-TrackedLibs issues that are tracked on the team's project board.Libs issues that are tracked on the team's project board.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.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.