Add array_chunks and array_windows?

[ronnodas]

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?

[ronnodas]

Another question, do we also want a remainder() or into_inner() method on ArrayChunks for the case where the length of the iterator isn't a perfect multiple of N? The into_inner() version is trivial, but to support accessing the remainder after exhaustion (via by_ref()), we may require more unsafe code (perhaps in methods on ArrayBuilder) and this possibly also makes the impl Clone for ArrayChunks more complicated (since MaybeUninit<T>: Clone only if T: Copy).

[jswrenn]

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]

I'd prefer array_chunks<0> to produce an inexhaustible iterator of empty chunks.

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 not ExactSizeIterator.

[jswrenn]

Yeah, good point. PME, please, then.