Open
Description
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<const N: usize>(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) #100026Final comment period (FCP)1Stabilization 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 be
Iterator::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 forN != 0
? (See also this same question in[T]::as_chunks
.)What's the tradeoff between the item type beingarray::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.)
Footnotes
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
the8472 commentedon Aug 13, 2022
It is definitely valuable to have a guaranteed, fixed length in the happy path. It aids vectorization and known-length specialization. It could even help in-place iteration in shapes like
vec.into_iter().array_chunks().map(...).flatten().collect()
.IndexedParallelIterator::arrays
rayon-rs/rayon#974rossmacarthur commentedon Nov 1, 2022
Might be good to align the naming of this function with
Iterator::next_chunk
, i.e. eitherIterator::chunks
Iterator::next_chunk
Or
Iterator::array_chunks
Iterator::next_array_chunk
(orIterator::next_array
)?camelid commentedon Nov 20, 2022
I think I'd vote for
Iterator::chunks
since arrays are a pretty clear fit for what this function accomplishes andarray_chunks
is a bit unwieldy.Iterator::array_chunks
toIterator::chunks
#104969adamse commentedon Dec 3, 2022
It seems good to follow the same naming conventions as
slice::array_chunks
#74985 where possible?andria-dev commentedon Dec 12, 2023
I think that the name
Iterator::array_chunks
is fine, but not great. The simple present tense of the verb 'to chunk' (i.e.Iterator::chunk
) could better indicate the action portion of organizing separate smaller units into single larger units. This should also avoid overriding the meaning of the plural noun 'chunks' as defined byItertools::chunks
(#104969 (comment)). As for following the naming convention ofslice::array_chunks
(#74985), it is also a nightly-only experimental API, so now should be a perfect time to change both as the above reasoning for usingchunk
applies there as well.GnomedDev commentedon Feb 20, 2024
An interesting unresolved question was brought up in #116000, should ArrayChunks::into_remainder return Option?
ronnodas commentedon Feb 21, 2024
I do not see the point of artificially converting an empty slice into a None, which needs to be unwrapped on use. Or semantically, it's not that the remainder is undefined, it just happens to be empty.
MapWindows
compile fail check for N=0 #1211562 remaining items