Tracking Issue for `slice_from_ptr_range`

[ibraheemdev]

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_range const #97419
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Will this get in the way of any future changes to the Range type(s) that we might want to make in a future version or edition?
  • This should probably switch to the new std::range types

[scottmcm]

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.

[WaffleLapkin]

@scottmcm current implementation uses sub_ptr which has these safety conditions:

• Both the starting and other pointer must be either in bounds or one byte past the end of the same allocated object.
• Both pointers must be derived from a pointer to the same object. (See below for an example.)

Which I think implies that both pointers must have the same provenance.

The current documentation of from_ptr_range already mentions that it must be the same allocated object, but it doesn't mention how the pointers must be derived...

• The range must contain N consecutive properly initialized values of type T:
  • The entire memory range of this slice must be contained within a single allocated object! Slices can never span across multiple allocated objects.

[WaffleLapkin]

Can someone add #97419 to the implementation history? It made the functions const under cons_slice_from_ptr_ranget and const_slice_from_mut_ptr_range features (this also should be added in the description). It also added a reexport of these functions to alloc and std, previously these functions were only accessible via core.

[wx-csy]

What's the behavior of these functions when T is ZST? Currently, the implementation calls pointer::offset_from, which panics if T is ZST. Maybe we have to add this to the documentation?