Add new iterator function .chunk()

[lilyball]

.chunk() takes a uint and yields owned vectors of that length.

r? @thestinger

[lilyball]

@cmr: Based on @thestinger's comments on my PR regarding Skip (#8375), I'm modifying this one as well (since it also tried to peg Some(uint::max_value) in the upper bound).

[lilyball]

r? @cmr

[lilyball]

@cmr Regarding your comment about a test for n >= num elts, that's actually covered by the existing test. In the first assert, the final chunk is n == num elts and in the second assert, the final chunk is n < num elts.

[emberian]

@kballard I remain unconvinced

[thestinger]

I don't think this is how we should implement chunk - it's going to be far too inefficient. It shouldn't require an allocation for every iteration - this kind of thing doesn't belong as an adaptor in std::iterator in my opinion unless we can do it efficiently and without special-casing container types like ~[T].

[thestinger]

For example, this could yield an iterator of iterators.

[lilyball]

@thestinger An iterator of iterators is actually a good idea. I originally wanted to yield &[A] but there's no way to do that safely. engla on IRC suggested that returning a ~[A] instead of &[A] is actually ok because you can't move out of an &[A] anyway. But I think an iterator of iterators is even better, because you can just call .to_owned_vec() to recreate the ~[A] approach.

I'm going to close out this PR for the time being, I'll re-submit when I've implemented @thestinger's idea (not sure when though, as I'm going on vacation).

[thestinger]

I'm not 100% sure it will work, but I think it will.

[lilyball]

@thestinger Upon thinking about it, I think this may hit the same issue that trying to yield &[A] does, which is you can't put a lifetime parameter on the &mut self arg to next(), so your resulting value can't have its lifetime tied to the ChunkIter. And because of that, the yielded iterators cannot keep a &mut ref to the underlying iterator (at least, not safely).

What it could do is buffer n elements into a ~[A] and yield the consume_iter() from that, but that's rather pointless compared to just yielding the ~[A] directly.

[nikomatsakis]

I am not sure if an iterator-that-yields-iterators can be done using the iterator trait and type system as it is today. As @kballard points out, it'd have to "give up" the underlying iterator temporarily, and the lifetime for which it would have to "give up" the underlying iterator is not known until you call next(), so it can't be encoded into the type you are iterating over.