Tracking issue for Box::into_raw_non_null

[SimonSapin]

This API was introduced in #46952:

impl<T: ?Sized> Box<T> {
    pub fn into_raw_non_null(b: Box<T>) -> NonNull<T> { /* … */ }
}

It is intended as an eventually-stable replacement for Box::into_unique, since there is no plan to stabilize Unique<T> at the moment.

See also discussion at #27730.

[SimonSapin]

It would be nice for this method to be an impl of the From trait instead, but coherence does not allow it since ptr::NonNull and Box are defined in separate crates. Having an Into impl without the corresponding From impl was frowned upon in the PR discussion.

This method can be replaced with unsafe { NonNull::new_unchecked(Box::into_raw(b)) }. This unsafe block is sound because Box is never null. Having a dedicated API removes the need for that unsafe block.

So while we can live without it, I’m still in favor of stabilizing this. It’s small and won’t be a maintenance burden.

[nvzqz]

I'm in favor of Box::into_non_null since we have Box::into_unique. Feels more consistent that way.

[SimonSapin]

@nvzqz Box::into_unique is unstable though, and I don’t know if it (or Unique) well even be stabilized.

[nvzqz]

I'm acutely aware it is. If we choose to stabilize both, then their names should be considered against each other regarding convention.

[mtak-]

Any movement on this? A cursory search of github for "new_unchecked into_raw" shows examples of the unsafe { NonNull::new_unchecked(Box::into_raw(b)) } pattern.

[luojia65]

Any further movements? This could be okay in my projects.