Implement parallel Range<i64> and Range<u64> #144
Conversation
These couldn't be exact iterators, because they could exceed a `usize` length on 32-bit targets. So this adds a `bridge_unindexed` helper function to drive consumers directly with imprecise splits. 64-bit ranges can use this while happily splitting in normal halves.
|
I wrote |
| @@ -83,6 +83,13 @@ pub trait UnindexedConsumer<ITEM>: Consumer<ITEM> { | |||
| fn to_reducer(&self) -> Self::Reducer; | |||
| } | |||
|
|
|||
| /// An unindexed producer that doesn't know its exact length. | |||
| /// (or can't represent its known length in a `usize`) | |||
| pub trait UnindexedProducer: IntoIterator + Send + Sized { | |||
There was a problem hiding this comment.
Great! One nit: I've always imagined that we would have Producer: UnindexedProducer; but I guess it's just kind of a lot of boilerplate.
I would think something like this:
impl<T: Producer> UnindexedProducer for T {
fn can_split(&self) -> bool { self.len() != 0 }
fn split(&self) -> (Self, Self) { self.split_at(self.len() / 2) }
}But I think we'd have to add the len method to Producer -- not that there is a good reason we don't have it.
Mostly I like the symmetry where you have:
ConsumerandUnindexedConsumer: ConsumedUnindexedProducerandProducer: UnindexedProducer
|
Going to merge this anyway. We can maybe refactor to give the producer traits more of a hierarchy later. |
|
Thanks! I agree that BTW, this should close #102. I had forgotten that issue existed when I wrote this, but it must have been floating in my subconscious already. :) |
Yeah, I can't think of any just now. =) I still like the idea of having the setup exposed (and it couldn't hurt), but I don't think it really matters, and if it does we can always do it then. |
These couldn't be exact iterators, because they could exceed a
usizelength on 32-bit targets. So this adds a
bridge_unindexedhelperfunction to drive consumers directly with imprecise splits. 64-bit
ranges can use this while happily splitting in normal halves.