Bool::into_option(closure) yields None or Some(closure())

[stebalien]

In this case, you’re probably right. It helps when you really don’t feel like writing a semicolon but an actual if statement is probably clearer.

Example:

fn get_name() -> Option<String> {
    read_stdin().iff(|s| !s.is_empty())
}

[Diggsey]

This is essentially short-circuit ‘and’ evaluation. If rust allowed overloading of the logical operators, you could do this:

(denominator != 0) && Some(numerator / denominator)

Much nicer IMO, and it doesn’t require a closure

[llogiq]

(denominator != 0) && Some(numerator / denominator)

Much nicer IMO, and it doesn’t require a closure

Sorry, but I have to disagree. The && operator is designed to do a short-circuit boolean AND. This works well because the types on both sides are booleans and the result also is. Now if you put Option into the mix, you’ll have to answer what happens when someone puts an option to the left side of the &&? What if we have an option on both sides?

let o1 = Some(..);
let o2 = None;
let b1 = true;
let b2 = false;

b1 && b2; // evaluates b1, then b2, returns false: bool
b1 && o1; // evaluates b1, then o1, returns Some(..): Option
b2 && o1; // evaluates b2, returns None: Option
o1 && b2; // ?
o2 && b1; // ?
o1 && o2; // ???
(b1 && o2) && (o1 && b2); // !?
o1 && b1 && o2 && b2 && Some("This is no longer funny"); // don't you agree?

Either we’d make the right-hand side type the result type (which would at least be a clear-cut rule), which could still confuse the hell out of people, or we’d make having a left-hand-side Option illegal (by not implementing the logical operator for this case), which would probably still be a footgun.

[Diggsey]

Sorry, but I have to disagree. The && operator is designed to do a short-circuit boolean AND. This works well because the types on both sides are booleans and the result also is. Now if you put Option into the mix, you’ll have to answer what happens when someone puts an option to the left side of the &&? What if we have an option on both sides?

Plenty of languages support short-circuit AND on non-booleans, eg. javascript - there’s nothing particularly problematic about it. The simplest rule would be to take the type of the right-hand side as you say, and all that’s required is that the RHS type has a “falsey” value, but you could equally well go the whole way and accept arbitrary types on both sides:

(a: A) && (b: B) where &A: Into<bool>, A: And<B>

=>

if a.into() { a.and(b) } else { a.falsey() }

Where And<B> has an associated type which determines the return type of both “a.and(b)” and “a.falsey()”

[DanielKeep]

<meta content-type="melodramatic-ranting/deliberately-overwrought;degree=slight">

The degree to which you’re willing to sabotage readability in pursuit of a trifling improvement in writing ergonomics is terrifying nay, horrifying.

Nothing but bool should have any sort of “truthiness”. The alternative leads to painful situations like Python’s old “midnight is False”, because everyone and their dog feels compelled to come up with some kind of “falsy” value for every type.

Even the smallest scrap of readability should be conceded only for significant gains. Losing “only bool is logical” to avoid some method calls is nowhere near enough.

Please, no. Just no.

---

Off-topic aside

eg. javascript - there’s nothing particularly problematic about it

I cannot find words to express how much I don’t agree with you.

[llogiq]

Thanks, DanielKeep. You wrote much more eloquently what I wanted to say. I only wanted to add that this leads to people being ‘clever’ instead of doing the clever thing and writing readable code.

I’m sure it wouldn’t have taken long for someone clever to figure out that ! matches all types, so he could write Perl: mybool || panic!(...).

[gkoz]

An alternative could be adding a to_option(self) -> Option<()> method and using existing map or and_then from Option.

trait BoolExt {
    fn to_option(self) -> Option<()>;
}

impl BoolExt for bool {
    fn to_option(self) -> Option<()> {
        if self {
            Some(())
        } else {
            None
        }
    }
}

The modified example: http://is.gd/OFszo8

[kstep]

I like it. But I’d favor a shorter name for to_option. Maybe to_opt? Or iff for that matter, as it was purposed here earlier.

[DanielKeep]

I’d be tempted to just copy+paste the methods from Option, and drop the closure argument, treating bool as though it were Option<()>. That way, there aren’t any new method names to learn.

[oli-obk]

type bool = Option<()>;
const false: bool = Some(());
const true: bool = None;

like Ada’s bool is a library-type called Boolean:

type Boolean is (False, True);

[gkoz]

[quote=“kstep, post:15, topic:1729, full:true”] I like it. But I’d favor a shorter name for to_option. Maybe to_opt? Or iff for that matter, as it was purposed here earlier. [/quote]The abbreviation would be frowned upon. And this function doesn’t feel like if. Maybe it could just be option.

[kstep]

Something along these lines?

fn divide(numerator: f64, denominator: f64) -> Option<f64> {
    (denominator != 0.0).map(|| numerator / denominator)
}

Looks interesting.

[stdsync]

I would be confusing by the name “map” here, as map always maps a function over one or more elements. Here, the function gets no arguments. to_option or and_then would be much better.

[kstep]

I’m for and_then then. It feels more familiar and rustish.

[gkoz]

Note that and_then takes a closure that returns Option so our example case would look like

(denominator != 0.0).and_then(|| Some(numerator / denominator))

This is no less verbose than to_option().map and somewhat confusing if you consider this method by itself.

[stdsync]

True. There may just be no useful and consistent API to add here.

[gkoz]

I’ve forgotten possibly the least intrusive variation: implementing Into<Option<()>> for bool which would give us Option::from(expr), so the example becomes

Option::from(denominator != 0.0).map(|_| numerator / denominator)

[stebalien]

That’s rather unintuitive. I’d expect Option::from(bool) to yield Some(bool):

impl<T> Into<Option<T>> for T {
    fn into(self) -> Option<T> {
        Some(T)
    }
}

[gkoz]

Oh, right. Option::from might just be ambiguous.

Why would Option::from(x) equal Some(x) when you can just Some(x)?

[stebalien]

For the same reason I proposed [Pre-RFC] From<T> for Result<T, E>. I’m not sure we should add that impl, but it’s a reasonable impl.