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

[bluss]

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.

[dobkeratops]

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-4.9.1.0/docs/Data-Either.html 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)

[steveklabnik]

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

Nothing has changed since my post on March 17.

[Pzixel]

We already have Either in futures crate. It’s also is confusing because it looks just like Either from either crate when it’s not.

Because Futures seems to be merged in std (at least very basic parts of it) could we also include Either there? It’s crucial to have them in order to be able to return impl Future from the function.

[Nemo157]

Note that futures(0.2) and futures(0.3-alpha) re-use either::Either instead of defining their own. Although, futures(0.3) can’t have impl Future for Either because of coherence, only Stream and Sink. So it’s likely going to drop that support and instead provide it’s own set of n-ary sum types.

[Centril]

I believe the state of art in n-ary coproduct (sum-type) hackery is provided by the frunk crate… it is probably way too much; but have a look at it

[canndrew]

I’ll just leave this here again: https://github.com/rust-lang/rfcs/pull/1154

[Nemo157]

I’m hoping we’ll eventually get either auto-generated delegating sum types, or variadic implementations on anonymous sum types. I’m gonna have to take another look at frunk to see if there’s some way to sort of emulate the second.

[Soni]

Either would be nice for things like splitting an iterator.

e.g.

let x: (Vec<_>, Vec) = iter.collect_split(|e| Left(e));

[cuviper]

Either would be nice for things like splitting an iterator.

That’s Itertools::partition_map.

[dcarosone]

If such a thing does go in std (and I’m not saying it should), can I make a small plea?

Don’t call the variants Left and Right, please pick names that are the same length so match blocks line up :). This annoys me every time I see it.

[Darsstar]

One/Two is not original enough I guess?

[earthengine]

This/That

[steveklabnik]

We used to have Either, but it was never used, so t was removed.

There’s a crate on crates.io for it.

[earthengine]

I think that was because we don’t have impl Trait at the moment. Bur now when we have it, it becomes essential to return different concrete types in different branches.

[steveklabnik]

The futures crate already provides an either for that case.

[earthengine]

The futures crate already provides an either for that case.

Yes, but impl Trait is not just for futures. It is now a core language feature, should have good library support as well.

[Centril]

I think we should consider extending the language with anonymous sum types instead.

A lot of the frunk crate is essentially a hack around that.

[Soni]

A|B types?

[Centril]

A|B types?

Yes, those; See also https://github.com/rust-lang/rfcs/issues/294