Tracking Issue for Iterator::array_chunks
· Issue #100450 · rust-lang/rust (original) (raw)
Feature gate: #![feature(iter_array_chunks)]
This is a tracking issue for Iterator::array_chunks
, an iterator adapter that allows to group elements of an iterator.
Public API
// trait Iterator
fn array_chunks(self) -> ArrayChunks<Self, N> where Self: Sized,self);
// core::iter
pub struct ArrayChunks<I: Iterator, const N: usize> { ... }
impl<I, const N: usize> ArrayChunks<I, N> { pub fn into_remainder(self) -> Option<array::IntoIter<I::Item, N>>; }
impl<I: Iterator, const N: usize> Iterator for ArrayChunks<I, N> { type Item = [I::Item; N]; }
impl<I: DoubleEndedIterator + ExactSizeIterator, const N: usize> DoubleEndedIterator for ArrayChunks<I, N> {} impl<I: FusedIterator, const N: usize> FusedIterator for ArrayChunks<I, N> {} impl<I: ExactSizeIterator, const N: usize> ExactSizeIterator for ArrayChunks<I, N> {}
Steps / History
- Implementation: Add Iterator::array_chunks (take N+1) #100026
- Final comment period (FCP)1
- Stabilization PR
Unresolved Questions
- Should
DoubleEndedIterator
be implemented?- Is there a use-case for this?
- In order to yield the same items either way we require
ExactSizeIterator
- Note that
.rev().array_chunks()
and.array_chunks().rev()
are different - If we decide to keep
DoubleEndedIterator
implementation should be improved
* For example, maybe there should beIterator::next_chunk_back
like there is for forward - Is the
unwrap_err_unchecked
innext_back_remainder
sound, despite not usingTrustedLen
? (I didn't block the original PR on this because it goes throughtake
, which I think we can trust, but I'd like someone smarter than me to think about it and confirm.)
- Should this be a type error for
N != 0
? (See also this same question in[T]::as_chunks
.) - What's the tradeoff between the item type being
array::IntoIter<T, N>
and the current one where the items are[T; N]
and there's a remainder? ([T]::array_chunks
has this question too and is unstable.)