Itertools Parity

List of methods taken from Itertools trait 0.7.4. For each method, leave some notes about how it might be done or if it makes any sense at all. Eventually these should move to proper issues, in which case it can be checked with a link to the issue instead. If you think a method makes no sense in parallel, move it to the bottom category ("inapplicable in Rayon").

Probably applicable but did not yet open issues

• step
• chunks
• tuples
• map_results
• with_position
• positions
• pad_using
• minmax
• minmax_by_key
• minmax_by
• collect_vec
  • (cuviper) I do use this sometimes to be lazier about type ascription. Plus, it pairs decently with collect_into that also targets Vec.

Uncategorized

• batching
• group_by
• merge
• merge_by
• merge_join_by
• kmerge
• kmerge_by
• coalesce
• unique
• unique_by
• peeking_take_while
• take_while_ref
• tuple_combinations
• combinations
• collect_tuple
• find_position
• all_equal
• dropping
• dropping_back
• concat
• set_from
• join
• format
• format_with
• fold_results
• fold_options
• fold_while
• sorted
• sorted_by

Done

• foreach -- #23 added for_each
• while_some -- #315 with unordered semantics
• partition_map -- #326
• fold1 -- same functionality as reduce_with
• fn interleave - https://github.com/nikomatsakis/rayon/issues/384
• fn interleave_shortest - https://github.com/nikomatsakis/rayon/issues/384
• fn intersperse - https://github.com/nikomatsakis/rayon/issues/385
• zip_longest - https://github.com/nikomatsakis/rayon/issues/386
• zip_eq -https://github.com/nikomatsakis/rayon/issues/386
• flatten -- https://github.com/nikomatsakis/rayon/issues/383
• update -- https://github.com/rayon-rs/rayon/issues/487

Opened issues

(none)

Maybe for some suitable base

A lot of the itertools method seem like they could work in limited cases -- specifically, iterators over cloneable, indexable collections (maybe this be modeled with IndexedParallelIterator + Clone as well?). Typically this is because of "boundary" conditions where parallel splits would otherwise be hard to adjudicate.

• dedup
  • the boundary conditions at the point of split are hard
• tee
  • this one is tricky, but potentially if we limited it to IndexedParallelIterator or something like that?
• tuple_windows
  • handling the overlap is hard, might be possible if we limited it to cloneable IndexedParallelIterator
• cartesian_product
  • under some conditions

Inapplicable in Rayon or very challenging

• next_tuple
  • inherently sequential ?