ACP: Add methods for converting bool to `Result<(), E>`

[LimpSquid]

Proposal

Problem statement

A common pattern found in application code is the conversion of a bool to a Result<(), E> and propogating the error with the ?-operator. Usually this leads to an intermediate conversion with bool::then_some and using ok_or[_else] to convert the boolean to an Err.

Motivating examples or use cases

Examples with the intermediate bool::then_some conversion can be found throughout many Rust codebases:

• https://sourcegraph.com/search?q=lang:Rust+then_some%5C%28%5C%28%5C%29%5C%29%5Cs*.ok_or.*&patternType=regexp&sm=0.

A simple example is given down below which will be used as base reference for the solution sketch.

#[derive(Debug)]
struct InvalidSyllable;

fn validate_syllables(syllables: &[&str]) -> Result<(), InvalidSyllable> {
    let allowed_syllables = [ "nan", "a", "ba" ];
    
    syllables
        .iter()
        .all(|syllable| allowed_syllables.contains(syllable))
        .then_some(())
        .ok_or(InvalidSyllable)
}

I propose new methods bool::then_err and bool::else_err for converting a boolean directly to a Result<(), E>, simplifying common patterns, aid in readability and reducing repetition.

Solution sketch

The snippet from the previous paragraph is refactored to make use of the proposed methods. For example purposes this is done with the use of a custom trait, but is expected to be implemented as methods on bool.

trait BoolExt: Sized {
    fn then_err<E, F: FnOnce() -> E>(self, f: F) -> Result<(), E>;
    fn else_err<E, F: FnOnce() -> E>(self, f: F) -> Result<(), E>;
}

impl BoolExt for bool {
    fn then_err<E, F: FnOnce() -> E>(self, f: F) -> Result<(), E> {
        match self {
            true => Err(f()),
            false => Ok(()),
        }
    }

    fn else_err<E, F: FnOnce() -> E>(self, f: F) -> Result<(), E> {
        match self {
            true => Ok(()),
            false => Err(f()),
        }
    }
}

#[derive(Debug)]
struct InvalidSyllable;

fn validate_syllables(syllables: &[&str]) -> Result<(), InvalidSyllable> {
    let allowed_syllables = [ "nan", "a", "ba" ];
    
    syllables
        .iter()
        .all(|syllable| allowed_syllables.contains(syllable))
        .else_err(|| InvalidSyllable)
}

fn main() {
    println!("{:?}", validate_syllables(&["ba", "nan", "a"]));
    println!("{:?}", validate_syllables(&["ba", "boon"]));
}

Alternatives

Could this be written using existing APIs?

Yes, using an intermediate then_some(()) is a valid approach used by many existing codebases. Alternatively one may decide to directly use the expression in an if-conditional or use an intermediate let-binding in case the conditional becomes hard to read.

[LimpSquid]

I've come to realize that this may not be the right place for this issue. If it doesn't belong here, please feel free to move or close it.

[tgross35]

This is the correct place!

However, constructing specifically a Result<(), E> is less flexible than constructing any Result<T, E>, and it is already pretty easy to write the more flexible version:

fn foo<E>(a: bool, e: E) -> Result<(), E> {
    // Achieves the proposed behavior
    a.then_some(()).ok_or(e)
}

fn bar<T, E>(a: bool, v: T, e: E) -> Result<T, E> {
    // Same but allows any `T`
    a.then_some(v).ok_or(e)
}

fn baz<T, E>(a: bool, f: impl FnOnce() -> T, e: impl FnOnce() -> E) -> Result<T, E> {
    // Lazy version
    a.then(f).ok_or_else(e)
}

[Amanieu]

We discussed this in the @rust-lang/libs-api meeting today. We agree that it would be useful to have methods that directly produce a Result<(), E> from a bool, however we did not like the names and instead preferred directly adding ok_or and ok_or_else methods on bool. As such we accept the ACP with the new signatures.

Please open a tracking issue and open a PR to rust-lang/rust to add it as an unstable feature. You can close this ACP once the tracking issue has been created.

[LimpSquid]

Please open a tracking issue and open a PR to rust-lang/rust to add it as an unstable feature. You can close this ACP once the tracking issue has been created.

Will do!

[kennytm]

preferred directly adding ok_or and ok_or_else methods on bool.

is the team confusing OP's proposal with tgross35's last comment? OP's suggestion are 2 distinct methods:

impl bool {
    pub fn then_err<E, F: FnOnce() -> E>(self, f: F) -> Result<(), E> {
        if self { Err(f()) } else { Ok(()) }
    }
    pub fn else_err<E, F: FnOnce() -> E>(self, f: F) -> Result<(), E> {
        if self { Ok(()) } else { Err(f()) }
    }
}

ok_or and ok_or_else could replace the proposed else_err function, but there's no correspondence to then_err.

[Amanieu]

We specifically rejected then_err and else_err because their naming was inconsistent with the existing then and then_some methods. Following that pattern, then_err/else_err would be expected to take an E directly and the variants taking a closure would be called then and else, both of which are unavailable (then is already a method, else is a keyword).

We judged that inverting the bool is simple enough in practice and the ok_or(_else) names are clearer and consistent with existing methods on Option.

[LimpSquid]

OP's suggestion are 2 distinct methods

As far as I understand we should only implement the else_err variant as ok_or[_else] similar to Option. Although it would be nice to have an equivalent variant for then_err, one can achieve similar behaviour using .not().ok_or(...). Having the ok_or[_else] variant would already be a useful addition to get rid of the .then_some(()).ok_or(...) construct.

[kennytm]

We judged that inverting the bool is simple enough in practice

Ok

As far as I understand we should only implement the then_err variant as ok_or[_else] similar to Option. Although it would be nice to have an equivalent variant for else_err, one can achieve similar behaviour using not().ok_or(...).

As far as I understand ok_or[_else] corresponds to the original else_err — it returns Ok on true, and Err on false.

[LimpSquid]

As far as I understand ok_or[_else] corresponds to the original else_err — it returns Ok on true, and Err on false.

Yes you are right, I made a mistake there but didn't edit it fast enough I suppose 😉.