contain-rs / ordered_iter Goto Github PK

• InnerJoinMap
• InnerJoinMapSet
• InnerJoinSet
• OuterJoin

(A::Key, (Option<A::Val>, Option<A::Val>)) is misleading because the Options cannot both be None. This could be

pub enum OuterJoin<T> {
    Left(T),
    Right(T),
    Both(T, T),
}

with the Item being (A::Key, OuterJoin<A::Val>), but the spatial metaphor is possibly confusing, and Option is more ergonomic.

The traits can be extended with additional methods that yield the difference and symmetric difference between two ordered iterators. The union is already handled by outer_join, and the intersection is already handled by inner_join.

I was toying around yesterday with hash join on iterators, which seems like it could fit in well with a library like this, but it doesn't require "ordered" iterators. Would it make sense to land it here (and possibly rename this to relational_iter), or to create a separate unordered_iter crate for these other algorithms?

The adaptor structs currently have the requirement that their keys implement Ord.

We now have two different conventions.