Repository navigation
Tracking Issue for slice_from_ptr_range #89792
Description
Feature gate: #![feature(slice_from_ptr_range)]
This is a tracking issue for slice::{from_ptr_range, from_mut_ptr_range}, counterparts to slice::{as_ptr_range, as_mut_ptr_range}.
Public API
// core::slice
pub unsafe fn from_ptr_range<'a, T>(range: Range<*const T>) -> &'a [T];
pub unsafe fn from_mut_ptr_range<'a, T>(range: Range<*mut T>) -> &'a mut [T];Steps / History
- Implementation: Add
slice::{from_ptr_range, from_mut_ptr_range}#89793 - Made const: Make
from{,_mut}_ptr_rangeconst #97419 - Final comment period (FCP)
- Stabilization PR
Unresolved Questions
- Will this get in the way of any future changes to the
Rangetype(s) that we might want to make in a future version or edition?- This should probably switch to the new
std::rangetypes
- This should probably switch to the new
Activity
scottmcm commentedon Mar 4, 2022
Is there anything about provenance that should be documented on these? Right now I think it always uses the provenance of the first pointer for what it puts in the slice; I'm not sure whether it would ever matter.
Rollup merge of rust-lang#97419 - WaffleLapkin:const_from_ptr_range, …
WaffleLapkin commentedon May 30, 2022
@scottmcm current implementation uses
sub_ptrwhich has these safety conditions:Which I think implies that both pointers must have the same provenance.
The current documentation of
from_ptr_rangealready mentions that it must be the same allocated object, but it doesn't mention how the pointers must be derived...Rollup merge of rust-lang#97419 - WaffleLapkin:const_from_ptr_range, …
WaffleLapkin commentedon Jun 2, 2022
Can someone add #97419 to the implementation history? It made the functions
constundercons_slice_from_ptr_rangetandconst_slice_from_mut_ptr_rangefeatures (this also should be added in the description). It also added a reexport of these functions toallocandstd, previously these functions were only accessible viacore.wx-csy commentedon Oct 2, 2022
What's the behavior of these functions when
Tis ZST? Currently, the implementation callspointer::offset_from, which panics ifTis ZST. Maybe we have to add this to the documentation?Rollup merge of rust-lang#129892 - oskgo:clarify-slice-from-raw, r=Ra…
Rollup merge of rust-lang#129892 - oskgo:clarify-slice-from-raw, r=Ra…
Unrolled build for rust-lang#129892