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

[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

[Soni]

Huh. I’d’ve thought the syntax would be more like:

let x = (&str, i32, i32)::2(1);
match x {
    <x>::0(s) => ...,
    <x>::1(i) => ...,
    <x>::2(j) => ...,
}

But okay… (this would be the opposite of a tuple - while a tuple’s attribute operates on values (t.0, t.1, etc), a summer’s attribute operates on types (T::0, T::1, etc))

(alternatively it wouldn’t support repeated types at all and construction and matching would be trivial)

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.