Tracking Issue for producing a `Result<(), E>` from a `bool`

[LimpSquid]

View all comments

Feature gate: #![feature(bool_to_result)]

This is a tracking issue for adding bool::ok_or and bool::ok_or_else as discussed in rust-lang/libs-team#606

This feature allows you to directly produce a Result<(), E> from a bool and is a short-hand for .then_some(()).ok_or(...) or .then_some(()).ok_or_else(|| ...).

Public API

assert_eq!(false.ok_or(0), Err(0));
assert_eq!(true.ok_or(0), Ok(()));

assert_eq!(false.ok_or_else(|| 0), Err(0));
assert_eq!(true.ok_or_else(|| 0), Ok(()));

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• Implementation: Add methods for converting bool to Result<(), E> #142749
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[LimpSquid]

I have attached a PR, but I have no permissions to update the S-Tracking-* label.

[amodam-user]

Is there a separate tracking issue for producing a more generic/flexible Result<T, E> from a bool, à la this comment on the original ACP?

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.

I saw this, but was unsure if it meant that only Result<(), E> conversions from bool would be supported. I can see an extension of the implementation that look something like (playground link:

trait BoolExt {
    fn ok_or<T, E>(self, t: T, e: E) -> Result<T, E>;
    fn ok_or_else<T, E, FT, FE>(self, ft: FT, fe: FE) -> Result<T, E>
    where
        FT: FnOnce() -> T,
        FE: FnOnce() -> E;
}

impl BoolExt for bool {
    fn ok_or<T, E>(self, t: T, e: E) -> Result<T, E> {
        if self {
            Ok(t)
        } else {
            Err(e)
        }
    }
    
    fn ok_or_else<T, E, FT, FE>(self, ft: FT, fe: FE) -> Result<T, E>
    where
        FT: FnOnce() -> T,
        FE: FnOnce() -> E
    {
        if self {
            Ok(ft())
        } else {
            Err(fe())
        }
    }
}

(If this is not the right place for this discussion, I apologize - please feel free to redirect to the appropriate channels).

[LimpSquid]

Is there a separate tracking issue for producing a more generic/flexible Result<T, E> from a bool, a là rust-lang/libs-team#606 (comment) on the original ACP?

Not yet. As @Amanieu mentioned, the ACP only covers converting a bool to a Result<(), E>. A more generic conversion could potentially be a useful addition. The issue is that your example wouldn’t remove the need for patterns like .then_some(...).ok_or_else(|| ...)¹ or .then(|| ...).ok_or(...)².

I'm not sure what the best place would be to take this discussion as I'm new to the process as well, zulip might be a good starting point.

---

Footnotes

1. https://sourcegraph.com/search?q=lang:Rust+then_some%5C%28%5B%5E%5C%28%5C%29%5D.%2B%5C%29%5Cs*.ok_or_else%5C%28&patternType=regexp&sm=0 ↩

2. https://sourcegraph.com/search?q=lang:Rust+then%5C%28%5C%7C%5C%7C%5B%5E%5C%28%5C%29%5D.%2B%5C%29%5Cs*.ok_or%5C%28&patternType=regexp&sm=0 ↩

[scottmcm]

trait BoolExt {
    fn ok_or_else<T, E, FT, FE>(self, ft: FT, fe: FE) -> Result<T, E>
    where
        FT: FnOnce() -> T,
        FE: FnOnce() -> E;
}

I, at least, am generally not fond of APIs like this that take two disjoint closures. They're pretty limiting since none of the analyses that rustc runs know that they're disjoint (there's no way to even express that in a signature so it could know), and thus lots of things that work fine with if don't work with double-closure APIs.

(https://doc.rust-lang.org/std/result/enum.Result.html#method.map_or_else is infamous for being kinda-bad in part because of this.)

[camsteffen]

Naming bikeshed.

I believe bool transformers like this should continue the then_ convention so that it is easier to infer that we are transforming a bool. Otherwise this looks too much like a Result method IMO. Also the "then" word helps me reason about what happens: "if it's true, then it's Ok".

// My brain says this is Result::ok_or
some_function().ok_or(0)

// Ah that's better.
some_function().then_ok_or(0)