[lib] Can we add an enum `Either` in std?


Sometime, I need to write a very simple enum type. Result type in std is not suitable for some cases, because the two variants in Result type suggest very different intentions.

I would very happy to see a generic Either type in std:

enum Either<T1, T2> {

If we can leverage variadic generics, it can be designed even better.

We could think of it as counterpart of tuple for convenience, one is for product type and the other is for sum type.

Is this type qualified to be added into std?


I expect the Rust idiom would be to create a more specific enum in most cases. Can you describe a use case for generic Either?


We used to have Either, but nobody used it, so we removed it.


will give you the above if you need it.


Thanks for your explanation.


As of now the official stance is that folks should define their own two-variant enums with domain-specific names. I have to admit that I sometimes want it though. The external crate is still probably the way to go though - slightly discourages its use but it’s still available.


In crate either, a trait problem is already apparent. It has some trait impls that make it easy to use for some drop-in use cases, and those block other reasonable choices for trait impls.

Specifically it covers I need a general “either this iterator or the other iterator enum” using an Iterator impl. That choice excludes Either from implementing IntoIterator instead.

The either crate may be a good choice if one needs it for a function argument and can’t name the situation more specifically.


I’m just trying something in haskell (rust as a gateway drug…) and found myself reaching for the ‘Either’ ;

I was also therefore curious to know if Rust had one;

r.e. making something domain specific with names, the appeal of Either here is that you’re already specifying two types (i.e. giving distinct names) (Either<FOO,BAR> … this node is either an FOO or a BAR’) , in some contexts those may be sufficient explain what is going on. tangentially, Imagine if the language actually had a ‘types not equal’ constraint (e.g. where A!=B) , which would enforce the ability to select by type (e.g. also imagine tuple accessors .get<A>(), .get<B>()) or .is<A>() .is<B>() for ‘either’ . https://github.com/rust-lang/rust/issues/42861 and imagine generalizing ‘a generic enum of 3 things’, etc.

I note that in haskell they do also fill out a load of helper functions around this. https://hackage.haskell.org/package/base- Also maybe there’d be utility in a ‘SoaVec<A,B> aswell’ with similar by-type accessor (although I guess macros could do that better for SOA stuff)


Nothing has changed since my post on March 17.