Publicly expose the `either!` macro?

[thomaseizinger]

The macro can be useful outside of this crate if one wants to deal with both variants in the same way but without them having the same type. For example:

trait Foo {
    type T;

    fn foo(self) -> Bar<Self::T>;
}

struct Bar<T> {
    inner: T,
}

impl<L, R, LT, RT> Foo for Either<L, R>
where
    L: Foo<T = LT>,
    R: Foo<T = RT>,
{
    type T = Either<LT, RT>;

    fn foo(self) -> Bar<Self::T> {
        let either_bar = either!(self, inner => inner.foo().inner);

        Bar { inner: either_bar }
    }
}

[cuviper]

We would need to change it to use $crate, but given that we already export some macros, this seems ok to me.

For public API, we should also consider whether either! is really a good name for what this does. That sounds like something that would construct an Either, but it's really more of a "map" operation -- map_either! perhaps?

[cuviper]

I guess it is basically the untyped version of Either::either, so maybe the name either! is ok.
(Whereas Either::map still returns an Either.)

[bluss]

I can't think of a good name off hand. I think we need something different than either - because the macro does not give you two choices- either left or right - it's based around mapping both Left => something and Right => something using just one "expression". Maybe either::both! wouldn't be entirely wrong, but it's awkward as a loose name without its crate.

[thomaseizinger]

I guess it is basically the untyped version of Either::either, so maybe the name either! is ok.
(Whereas Either::map still returns an Either.)

Not quite. The main difference is that either! only takes one closure! Whereas the function takes two!

Maybe for_each or for_both would be appropriate?

On the topic of names: Either::either is functionally similar to futures::select!.

[bluss]

Yes, that sounds good to me, with preference to for_both (it's not each - as it's not a container of left and right?)