Yield a custom struct from OuterJoinIterator

[apasel422]

(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.

[erickt]

I think this makes sense. It fits in well with the relational left inner join and right inner join, which I expect will be eventually implemented.

[Gankra]

This was discussed offline. I pointed out that it may be more ergonomic to use Options just because Options are Options. Also it makes handing "had left" uniform whereas this design makes "had left" a two-case situation (either Left or Both).

Without usecases it's not clear that either design is better or worse.

[ghost]

How about adding a to_options method to OuterJoin<T>, giving the best of both worlds.

fn to_options(self) -> (Option<T>, Option<T>);

[Gankra]

@csherratt My only concern is overhead, but I suppose iterators are supposed to be inlined to annihilation, so that seems like a decent compromise.