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

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.

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.

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