-
Notifications
You must be signed in to change notification settings - Fork 328
Open
Description
Now that next_array
exists, it's not so hard to write the methods array_chunks
(functionally equivalent to from_fn(|| self.next_array())
) and array_windows
, similar to the unstable slice::array_chunks
and slice::array_windows
respectively. However it's similarly unclear what array_chunks<0>
and array_windows<0>
should do. Does it make sense to emit a post-monomorphization (but still compile-time) error, via say const { assert!(N > 0) }
? Or is it better to produce run-time errors?
Is the name arrays
preferable to array_chunks
, to be consistent with Itertools::tuples
?
sjackman and mcobzarenco
Activity
ronnodas commentedon Mar 2, 2025
Another question, do we also want a
remainder()
orinto_inner()
method onArrayChunks
for the case where the length of the iterator isn't a perfect multiple ofN
? Theinto_inner()
version is trivial, but to support accessing the remainder after exhaustion (viaby_ref()
), we may require more unsafe code (perhaps in methods onArrayBuilder
) and this possibly also makes theimpl Clone for ArrayChunks
more complicated (sinceMaybeUninit<T>: Clone
only ifT: Copy
).jswrenn commentedon Mar 2, 2025
A PME is always preferable to a runtime error, but, if possible, I'd prefer
array_chunks<0>
to produce an inexhaustible iterator of empty chunks.We definitely want a
remainder()
method, but we have a high bar for merging unsafe code. If the needed unsafe code turns out to be trivial, we'd be more likely to merge it.scottmcm commentedon Mar 2, 2025
I'd suggest not doing that, actually, because while it's implementable, it means that it'd be no longer be correct to
impl<I: ExactSizeIterator> ExactSizeIterator for ArrayChunks<I, N>
-- an infinite iterator is notExactSizeIterator
.jswrenn commentedon Mar 2, 2025
Yeah, good point. PME, please, then.