Either crate style methods for EitherOrBoth

[Avi-D-coder]

I have recently been using zip_longest. Without Functors or lens it's a bit of a pain.
@bluss's either crate has methods to make dealing with either variants nicer, so I added some of them. I attempted to make the naming and implementation as similar as possible, but there are a few differences.

A fallible method of converting EitherOrBoth into an either would be very useful providing exclusive (not including Both variant) methods. Converting should probably wait for rust-lang/rust#33417.

[bluss]

I think the defintion of is_left is well-intentioned but in practice it becomes a confusing conflict with has_left. I would for that reason leave those methods out.

[Avi-D-coder]

Would you consider keeping them with names like only_left, only_is_left or using the prefix just_?
That way those of us that need this functionality don't have use an additional crate containing just:

trait IsDirection {
    fn is_left(&self) -> bool;
    fn is_both(&self) -> bool;
    fn is_right(&self) -> bool;
}

impl<a, b> IsDirection for EitherOrBoth<a, b> {
    fn is_left(&self) -> bool {
        match *self {
            Left(_) => true,
            _ => false,
        }
    }

    fn is_right(&self) -> bool {
        match *self {
            Right(_) => true,
            _ => false,
        }
    }

    fn is_both(&self) -> bool {
        self.as_ref().both().is_some()
    }
}

This brings up an issue, the merits of an either_or_both crate.
Obviously their must be a cut off, If people end up needing all of either's methods and trait implementations then a separate crate would be a good idea. As it stands now I don't think people use EitherOrBoth enough to justify a crate or the even including all the methods in either.

The only method not included in this pull is that would advocate be included is combine . I prefer the name reduce for this method. It serves as a sort of analog to the either() method.

impl<T> EitherOrBoth<T, T> {
    pub fn combine<F>(self, f: F) -> T
    where
        F: FnOnce(T, T) -> T,
    {
        match self {
            Left(a) => a,
            Right(b) => b,
            Both(a, b) => f(a, b),
        }
    }
}

What are your thoughts on combine/reduce?
Would you like any other methods to be added to this pull request?

[Avi-D-coder]

@bluss If you get a chance can you take a look at this again?

[Avi-D-coder]

Bump

[jswrenn]

Sorry for taking so long to get to this!

Would you consider keeping them with names like only_left, only_is_left or using the prefix just_?

After some soul searching, I've decided that the benefits of sticking with the is_variant naming convention outweigh the potential for conflation with has_{left,right}.

Could you revert f5bfc64, squash, and rebase on master?

[Avi-D-coder]

Should be ready to go

[jswrenn]

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push