[benschulz]

I wish there was an `Either` type in std. I realize that there used to be one and we have `Result` now. However, now that we have `impl Trait` it's worth revisiting, I believe. If we don't we'll have the one from `itertools`, the one from `futures` etc.

In most GCed languages it wouldn't matter so much because you'd return a boxed `Iterator` or `Future` or what have you. But in Rust you generally want to avoid the allocation.

[paavohtl]

IMHO most of the time it's better to create a special 2-case enum for your specific use case. It's 3 lines of code, which gives you significantly clearer naming than "Either" and "Left/Right".

[throwaway6734]

I ran into this recently and solved the problem via Enums. Not sure of the performance impact.

[the_mitsuhiko]

I think most people end up regretting code that users itertools::Either at the moment and use it reluctantly.

[benschulz]

Can you expand on that? As long as the public type is opaque I don't see what there is to regret.

[zaarn]

As someone with difficulties telling left and right apart, using Either isn't particularly straight forward. This plus the left and right variant become meaningless on their own.

Ie, if I wanted an enum of either a string or an integer, it becomes "Either<&str, i64>".

But what I wanted is that it's either a string identifier or the database Id of something to be later referenced, which might be better described as "enum IdentOrDbId { Ident(String), DbId(i64) }".

This is of course a much simplified example of things I've faced.

[benschulz]

Sorry, based on the replies I'm getting I did not make myself clear. I only want to use Either in cases like the following.

    fn some_func() -> impl SomeTrait {
        if some_condition {
            Either::Left(a)
        } else {
            Either::Right(b)
        }
    }

Both a and b will implement SomeTrait which is all callers care about. However, because they're structurally different they must be wrapped in an Either that delegates all methods from SomeTrait to a or b respectively.

[codeflo]

I don't think that would work in general: trait methods can have signatures for which you can't synthesize an implementation for the sum type (something that takes a second Self as an argument, like std::ops::Add, comes to mind).

For object-safe traits where this would be possible, you can at least do this at the cost of an allocation, as you probably know:

  fn some_func() -> Box<dyn SomeTrait> {
      if some_condition {
          Box::new(a)
      } else {
          Box::new(b)
      }
  }

[the_mitsuhiko]

The moment you have an Either::Left(Either::Left(x)) you're starting to revisit everything. Yet that's what happens with impl Iterator a lot when you have branches.