Tracking Issue for additional `array::IntoIter` constructors (feature `array_into_iter_constructors`)

[scottmcm]

Feature gate: #![feature(array_into_iter_constructors)]

This is a tracking issue for the from_raw_partsnew_unchecked and empty constructors on core::array::IntoIter.

This allows creating such an iterator with something other than a fully-initialized array.

Public API

// core::array

impl<T, const N: usize> IntoIter<T, N> {
    pub const fn empty() -> Self;
    pub const unsafe fn new_unchecked(buffer: [MaybeUninit<T>; N], initialized: Range<usize>) -> Self;
}

Steps / History

• Implementation: Add array::IntoIter::{empty, from_raw_parts} #91341
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Should this be named from_raw_parts or something else?
• Should this have to go through an ArrayVec-like type (like how Vec has from_raw_parts instead of vec::IntoIter having it), instead of making the IntoIter directly?
• What's a good name for new_unchecked? It was previously from_raw_parts, but was changed at reviewer request in the initial PR. Then after that, new was deprecated, which makes me feel like new_unchecked is a bit odd too.
  • Add Iterator::next_chunk #93700 (temporarily) added a duplicate of this called with_partial, so that's another possible name.
• Can new_unchecked take R: RangeBounds? To allow this to work with the new range types.

[scottmcm]

Hmm, I noticed today that these methods are, arguably, pessimizing the array iterator slightly. new gives it a valid array, so it could be using ManuallyDrop instead of MaybeUninit.

Does that actually matter? Dunno. But it's a foundational difference between an array builder and an array drainer.

[clarfonthey]

I would definitely like to see an implementation of Default for IntoIter that uses empty(), although that would be insta-stable and require an FCP.