Either constructors from bool

[asibahi]

Hello.

I am curious if this was discussed or considered before. I searched the issues and PRs (for "bool") and found nothing similar.

Basically something like this:

trait Eitherable {
    fn either<L, R>(&self, left: L, right: R) -> Either<L, R>;
    fn either_else<L, FL: FnOnce() -> L, R, FR: FnOnce() -> R>(
        &self,
        l_func: FL,
        r_func: FR,
    ) -> Either<L, R>;
}

impl Eitherable for bool {
    fn either<L, R>(&self, left: L, right: R) -> Either<L, R> {
        if *self {
            Left(left)
        } else {
            Right(right)
        }
    }

    fn either_else<L, FL: FnOnce() -> L, R, FR: FnOnce() -> R>(
        &self,
        l_func: FL,
        r_func: FR,
    ) -> Either<L, R> {
        if *self {
            Left(l_func())
        } else {
            Right(r_func())
        }
    }
}

which allows nice one liner constructors like this :

my_bool.either(left_value, right_value)

instead of

if my_bool {
        Either::Left(left_value)
} else {
        Either::Right(right_balue)
}

Similarly for Options

[cuviper]

You removed Option from the title, but that was briefly discussed in #15. The symmetry mentioned there is stated in the documentation for Either:

The Either type is symmetric and treats its variants the same way, without preference. (For representing success or error, use the regular Result enum instead.)

I think this applies to bool as well -- there's no inherent mapping that says true should be Left or Right.

[asibahi]

I did remove Option since I did see that issue. The reasoning there made sense and the function I wrote doesn't make sense when applied to Options.

My rationale for treating Left as truthy is basically just that the visual order: if cond { Left(left) } else { Right(right) } orders them the same as cond.either(left, right).

I have been informed that Haskell (for example) generally treats Right as truthy as well.

[cuviper]

I have been informed that Haskell (for example) generally treats Right as truthy as well.

"as well"? Doesn't that contradict the Left-truthy position you're advocating?

The derived Ord and PartialOrd also support that direction, where false < true and Left(_) < Right(_).

But I think truthiness is still a kind of preference that we're trying to avoid. Haskell is more opinionated:

The Either type is sometimes used to represent a value which is either correct or an error; by convention, the Left constructor is used to hold an error value and the Right constructor is used to hold a correct value (mnemonic: "right" also means "correct").

[asibahi]

Meant "as well" as in adding to what you said.

I understand why you might not want to add this to this crate. I think I will try creating a crate of my own implementing them, as it would be also a learning experience for me. Thanks for the comments.

[cuviper]

Got it. Okay, I think we can leave it to your crate to offer a more opinionated stance. :)