add split operation on indexed parallel iterators

[nikomatsakis]

Currently given an IndexedParallelIterator there is no way to divide it up other than skip/take which have side-effects. We were discussing the possibility of a split that takes an indexed iterator and yields back two of them around a particular index.

[cuviper]

Hmm, I started implementing this, but it's awkward for iterators that own their data, like rayon::vec::IntoIter. (Whereas its VecProducer only holds &mut [T], which can split.)

[nikomatsakis]

@cuviper ah, interesting -- very good point =)

The fundamental thing that makes it awkward is that the two returned iterators need to be able to be dropped independently (per this design).

You really would prefer to be iterating over this stuff in place though. Hmm.

[cuviper]

Once is also awkward to return (Self, Self), unless we allow one of those to not actually iterate once.

Enumerate will have to track its start index, which it doesn't now until it's a Producer. And similar to Once, would it be weird to have an instance of Enumerate floating around that doesn't start at 0?

Or an Interleave that starts with an item from the second iterator? Or an Intersperse that starts with the interspersed item?

[nikomatsakis]

It seems to me that there are enough design questions that it is worth taking this off the 1.0 milestone and iterating separately -- we can always add a SplittableIndexedIterator or something.

In any case, I think we are going to want this to be a callback style, like producer, so that the types can vary and not be limited by associated types.

[cuviper]

Ah, add a separate trait because we're talking about a required method -- right.

I agree on delaying it. When we get an RFC process going, this will be a good one to chew on. I'm also playing with a simpler trim like I mentioned in #352, or maybe called slice or range...