Impl Try for bool

[canndrew]

Can we have this?

impl Try for bool {
    type Ok = ();
    type Error = ();

    fn into_result(self) -> Result<(), ()> {
        if self { Ok(()) } else { Err(()) }
    }

    fn from_error((): ()) -> bool {
        false
    }

    fn from_ok((): ()) -> bool {
        true
    }
}

I want this quite often when I want to do a bunch of checks and get false if any of the checks return false. Having bool implement Try will mean I can do that without using chains of combinators.

As far as I’m concerned bool is basically just shorthand for Option<()> which is basically just shorthand for Result<(), ()>, and we already have this for Option<T> and Result<T, E>.

[canndrew]

Speaking of which, it’d be nice to have functions to downcast from Result<(), ()> to Option<()> and Option<()> to bool. Result::ok and Option::is_some can be used but I’d like functions that explicitly don’t throw away any data.

[scottmcm]

Some previous places this has come up:

[Pre-RFC] Elvis/coalesce + ternary operator

Well, speaking of ?, we could spitball using the Try trait for A || B: if let Ok(v) = Try::into_result(A) { Try::from_ok(v), } else { B } This would be consistent with the current bool behaviour given an implementation like this: struct True; struct False; impl Try for bool { type Success = True; type Error = False; fn into_result(self) -> Result<Self::Ok, Self::Error> { if self { Ok(True) } else { Err(False) } } fn from_error(False: Self::Error) -> Self {…

Something for coalescing; aka generalized/improved `or_else`

I think the only operator that would make sense is ||. It’s already lazy, as this one would be, and currently isn’t overloadable so it wouldn’t break anything. (And you can imagine a impl Try for bool where b? short-circuits on false which would be perfectly consistent with this definition, though I suspect we don’t actually want to allow ? on bool.) OTOH, maybe just the macro would be enough. A bunch of the try{} discussions have talked about “what if I just want to return the first success…

Idea: Early returns and irrefutability

I don’t think you have to do any of this trickery. Parse it as let <pat> = (<expr> || <expr>);. Have a transformation that depending on context makes the || expand to { let temp = <lhs>; if temp { temp } else { <rhs> } or let <pat> = match <lhs> { <pat> => <pat>, _ => <rhs>. Or if we’re ok with || only working with Try types rather than with refutable patterns, add impl Try for bool and desugar || to (approx) match <lhs>.as_result() { Ok(t) => typeof::<lhs>::from_ok(t), => <rhs> }. We have a …

And of course there's

boolinator

I'd personally have no complaints with bool: Try.

[hyeonu]

+999, but it needs to be type Error = FalseError for the same reason of NoneError.

[mcy]

Unfortunately, I don’t think this will have the right precedences: !cond?. That alone makes me a bit skeptical that this is a good idea. This won’t compile but having to write (!cond)? is a bit surprising.

[timvermeulen]

The version with parentheses looks more readable to me, so I don’t mind that they’re required there.

[josh]

@canndrew

do a bunch of checks and get false if any of the checks return false.

Can you show an example of the kind of code you want to write?

Would && help you here?

[kornel]

Maybe it’d suffice to add equivalent of .ok_or() to bool?

boolean_result().true_or(Error::FalsyThing)?;

[zackw]

@canndrew

    fn from_error((): ()) -> bool { false }
    fn from_ok((): ()) -> bool { true }

Zero / false meaning success is perhaps not as common as zero / false meaning failure, but it is commonly encountered -- for instance both Unix and Windows system calls use zero for success and some nonzero code for failure (if they don't have some other token to return). So I do not think this mapping is universal enough to be put in the stdlib, and unfortunately that torpedoes the entire concept.

[zackw]

@kornel

boolean_result().true_or(Error::FalsyThing)?;

If we can have false_or as well, then I do endorse this idea.

[josh]

That’s much less common when using an actual bool type.

But I do agree that the semantics and types seem like they shouldn’t be in std/core.

[canndrew]

@zackw

Zero / false meaning success is perhaps not as common as zero / false meaning failure, but it is commonly encountered

You end up having the same polarity problem with Option and Result though. Occasionally I want to write code that returns early on the first Ok (or Some) but otherwise runs to the end collecting errors.