Trait generic over core::iter::Iterator and rayon::iter::ParallelIterator

[sanmai-NL]

I want to return a type that’s core::iter::Iterator from a function, using impl Iterator syntax. Since Rayon has adopted a different trait, rayon::iter::ParallelIterator, my only option seems to leak implementation details and return impl ParallelIterator.

What can be done about this?

[cuviper]

Converting to an Iterator is #210, and we don't yet have a good idea how to actually implement that.

A generic trait covering both Iterator and ParallelIterator sounds interesting. While they are only similar, not actually identical, I do think it would be possible to wrap a common subset of functionality. However, I don't think we could implement such a thing generically, as you would want two blanket implementations for I: Iterator and for I: ParallelIterator, which requires proving to the compiler that these are exclusive. Maybe with specialization this would be possible, by also implementing the union I: Iterator + ParallelIterator as the most specific case (even though I don't know any type that actually fits that).

[sanmai-NL]

@cuviper:
Would it be a good solution if a type parameter Ordering were added to the Iterator trait that defaults to, say, Sequential? #210 doesn’t yet come with an analysis about what distinguishes an iterator from a parallel iterator in a sense relevant to the Iterator trait as currently defined.

[cuviper]

How would a type parameter help your use case? You would still be forced to "leak" that information by writing impl Iterator<Sequential> -- it can't be left unstated. And still, the actual trait methods are still too different -- even the fundamental Iterator::next is not present at all in ParallelIterator.

[cuviper]

I was reminded today of a little experiment I did:
https://users.rust-lang.org/t/dynamically-using-or-not-using-rayon/18327/6
https://github.com/cuviper/rayon-cond

I haven't published it, but I'm considering. This adds a new wrapper type which has its own API that is a common subset of Iterator and ParallelIterator. In your case, you could write something like:

fn foo(...) -> CondIterator<impl ParallelIterator<Item = T>, impl Iterator<Item = T>>

Thus returning a type that is iterator-like, without committing to being parallel or serial. Internally, you could use an Empty<T> placeholder type for the side you're not actually using.

[ExpHP]

I just found myself needing this again today, this time so I can work around the issue of how cargo test cannot capture output from other threads (rust-lang/rust#42474, #597).

Would be great to see it published or added to rayon!

[cuviper]

I finally got around to publishing rayon-cond -- feedback welcome on that repo!

I think that's about as close as we can get, since the APIs are subtly different, so I'm going to close this issue. If anyone has new ideas, feel free to re-open or start a new issue.