Tracking Issue for `new_zeroed_alloc`

[workingjubilee]

Feature gate: #![feature(new_zeroed_alloc)]

Split-out from #63291 as a result of stabilizing most of its API! It's zeroed instead of uninit constructors, nothing too complicated!

Public API

It's new_zeroed and new_zeroed_slice on every major allocation type like Box, Rc, Arc.

impl<T> Box<T> { pub fn new_zeroed() -> Box<MaybeUninit<T>> {…} }
impl<T> Arc<T> { pub fn new_zeroed() -> Arc<MaybeUninit<T>> {…} }
impl<T> Rc<T> { pub fn new_zeroed() -> Rc<MaybeUninit<T>> {…} }

impl<[T]> Box<T> { pub fn new_zeroed_slice() -> Box<MaybeUninit<[T]>> {…} }
impl<[T]> Arc<T> { pub fn new_zeroed_slice() -> Arc<MaybeUninit<[T]>> {…} }
impl<[T]> Rc<T> { pub fn new_zeroed_slice() -> Rc<MaybeUninit<[T]>> {…} }

Steps / History

• Implementation: #...
  • added in alloc: Add new_zeroed() versions like new_uninit(). #66128
  • other API was added in Tracking issue for uninitialized constructors for Box, Rc, Arc #63291
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• idk lol

Footnotes

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

[coolreader18]

This seems pretty straightforward - are there any blockers to stabilizing this as-is? It's a mirror of the new_uninit API family, in the same way that MaybeUninit has both uninit() and zeroed(), so it's following established patterns and logically filling out the set of APIs.

[thaliaarchi]

I think this feature is ready, so have opened #144091 to stabilize this.

Stabilization report

The corresponding new_uninit and new_uninit_slice functions were stabilized in #129401, but the zeroed counterparts were left for later out of a desire to stabilize only the minimal set. These functions are straightforward mirrors of the uninit functions and well-established. Since no blockers or design questions have surfaced in the past year, I think it's time to stabilize them.