Remove std::either

[brson]

It's rarely used and usually it's better to define a custom enum type.

[catamorphism]

I agree. I can't think of a situation where using Either is preferable to defining a more informative type.

[bluss]

I'm looking at what current uses of Either can be migrated/refined. Some of them are using it just like a Result.

[bluss]

What do you think about these two? They don't exactly follow the pattern of Result since instead of a value or an error description, they represent two kinds of values.

libstd/rt/kill.rs:    pub fn try_block(mut task: ~Task) -> Either<~Task, BlockedTask> {
libstd/unstable/sync.rs:    pub fn try_unwrap(self) -> Either<UnsafeArc<T>, T> {

[wakandan]

Hi I'm new to Rust and want to contribute. My friend recommends I should take this as the first step so I decided to give it a try. Can I take this? Thanks.

[jdm]

@blake2-ppc Are you doing any further work here, or can @wakandan take over removing all traces of Either?

[wakandan]

@jdm still very noob here, but will try my best!

[bluss]

I won't do anything here. @wakandan can go ahead.

I have my concern though that maybe Either is the best thing to keep around for cases like the return value of the two pub functions I listed in my comment previous. Just like it's convenient to return a tuple instead of a custom type, Either is maybe the best choice(?).

[wakandan]

Thanks @blake2-ppc. I was fetching from the upstream of rust but couldn't see your #9180. What am I missing here?

[bluss]

It was merged, you should see it if you check out new enough master

commit 1c26513ef9a58fa3e6703320cc37427aa229bbbd
Merge: 5d905f1 15c9dc7
Author: bors <bors@rust-lang.org>
Date:   Sat Sep 14 08:50:50 2013 -0700

    auto merge of #9180 : blake2-ppc/rust/reduce-either, r=catamorphism

[Kimundi]

@blake2-ppc: I think @brson's intention was to replace such cases with an custom enum type.
@wakandan: For handling those cases (Either types that don't describe an 'success'/'failure' duality), do this for each distinct use case:

• Find out for what specific reason it uses an Either.
• Find a good name for a new enum that describes that duality, and create it.
• If the code used methods of Either, duplicated them into the new enum type, and maybe specialize them for the specific use case (which mainly means replacing 'either', 'left' and 'right' terminology).

[bluss]

Yes kimundi, I just mean this

Just like it's convenient to return a tuple instead of a custom type, Either is maybe the best choice(?).

A public API might be easier to use if Either is used as the recurring alternative type, just like tuples are sometimes used instead of creating custom types for each time a pair of values returned.

[Kimundi]

@blake2-ppc Hm, I agree in principle, but we'd really need types for two, three, four, ... variants there.

Maybe we could define the Either operations as an trait, and add an deriving mode for custom enums?

Or just predefine a bunch like with tuples.