Tracking Issue for `box_vec_non_null`

[theemathas]

Feature gate: #![feature(box_vec_non_null)]

This is a tracking issue for convenience methods for conversion between NonNull and Vec/Box.

Public API

impl<T: ?Sized> Box<T> {
    pub unsafe fn from_non_null(ptr: NonNull<T>) -> Self { .... }
}
impl<T: ?Sized, A: Allocator> Box<T, A> {
    pub const unsafe fn from_non_null_in(raw: NonNull<T>, alloc: A) -> Self { .... }
    pub fn into_non_null(b: Self) -> NonNull<T> { .... }
    pub fn into_non_null_with_allocator(b: Self) -> (NonNull<T>, A) { .... }
}
impl<T> Vec<T> {
    pub unsafe fn from_parts(ptr: NonNull<T>, length: usize, capacity: usize) -> Self { .... }
}
impl<T, A: Allocator> Vec<T, A> {
    pub unsafe fn from_parts_in(ptr: NonNull<T>, length: usize, capacity: usize, alloc: A) -> Self { .... }
    pub fn into_parts(self) -> (NonNull<T>, usize, usize) { .... }
    pub fn into_parts_with_alloc(self) -> (NonNull<T>, usize, usize, A) { .... }
    pub fn as_non_null(&mut self) -> NonNull<T> { .... }
}

Steps / History

• Implementation:
  • ACP: Box/Vec/slice convenience NonNull methods libs-team#418
  • Implementation PR: Add NonNull convenience methods to Box and Vec #130061
  • ACP 2: Vec::as_non_null() method libs-team#440
  • Implementation PR 2: Add Vec::as_non_null #130624
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[scottmcm]

One thing I wanted to bring up here in terms of the "parts" name: I think from_parts is a great name, but I wonder if this is the right split to get that nice short name. Especially if we ever got another pointer type -- perhaps an aligned one -- it's not super-clear to me that NonNull is necessarily the right phrasing to get the shortest name.

Spitballing, what about something like this

impl<T, A> Vec<T, A> {
    pub const unsafe fn from_parts(buffer: Box<[MaybeUninit<T>], A>, initialized: RangeTo<usize>) -> Self;
    pub const fn into_parts(self) -> (Box<[MaybeUninit<T>], A>, RangeTo<usize>);
}

where it's no longer possible to accidentally get the capacity and length -- which have the same type, so the compiler doesn't help! -- in the wrong order. And the precondition for from_parts is simpler, because it only needs to talk about initializedness: everything about ownedness/readability/writability of the allocation comes from the Box. Could even have a safe version that takes the Box and gives a zero-length Vec, leaving it for you to set_len later to the initialized part, though I probably wouldn't want that as the only option.

And it doesn't need to have a separate function for an allocator-aware version because dealing in Box handles that.