`<[T]>::[array_]windows` (and chunks?) function family could allow 0 length

I agree with the general assessment that this might be the case, but nonetheless it would be interesting to find some concrete example of “algorithms(s) built on top of windows” to see whether this will actually handle edge cases of any reasonable, practical algorithms :slight_smile:


The chunks case on the other hand sounds a bit too much like division by zero, in particular, [].chunks(0) seems hard to define in any particularly nice way, just as dividing zero by zero (whereas for positive numbers divided by zero, the answer “(positive) infinity” is – at least – the unique answer following limit arguments). The obvious problem is that [].chunks(n) is always empty, whereas […non-empty…].chunks(0) is always infinitely long, so you have an argument for [].chunks(0) to be empty, but also an argument for it to be infinitely long (and possibly, by some different “limit”-style argument, you can also argue for anything in-between).

Another interesting effect of defining both chunks and windows as you proposed would be that every case except zero has chunks return a subsequence of windows, but for 0 the chunks suddenly are a lot more than the windows… so that’s maybe a bad edge-case after all? Another problem is ExactSizeIterator, which cannot be implemented correctly for any infinite chunks iterator (as it doesn’t support infinite iterators), and arguably you will probably want this trait for ArrayChunks, too (and restricting it to N != 0 on the type level might require some language features we don’t have yet).

8 Likes