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

[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.

[llogiq]

I think that the ‘usual’ method names of Option would only confuse people. I don’t want us to build clever little footguns to trip up other programmers.

If we really want one, the method on bool should have a completely different name than any Option method, as to minimize confusion. On the other hand, the name should be short and meaningful.

My .02$:

• _.and_some(_)
• _.as_opt(_)
• _.some(_)
• _.then(_)
• _.opt(_)

Currently, then would be my favourite name. Similar enough to and_then, yet different enough not to be confused.

By the way, how strong does negation bind? I’d hate to see someone complaining because !b.then(x) didn’t work as expected…

Edit: method application binds more strongly than bool negation: http://is.gd/QHpi1c – yes, removing parenthesis just results in a (somewhat understandable) compiler error. Still, this is a footgun.

[oli-obk]

Wow this yielded quite some discussion.

I have come to the conclusion that if x { Some(y) } else { None } is way more readable than any of the proposed closure functions. It should be made totally clear what’s going on. Short circuiting boolean operators is definitely not the way to go. Using booleans as anything but booleans breaks the code-reading flow. So here’s a macro that’s not worse than the closure solutions imo. Not saying it’s better though.

macro_rules! opt (
    ($cond:expr => $some:expr) => {
        if $cond { Some($some) } else { None }
    }
);

fn test(cond: bool) -> Option<i32> {
    opt!(cond => 5)
}

[llogiq]

You could also simply define

fn opt<T>(b: bool, t: T) -> Option<T> {
    if b { Some(t) } else { None }
}

and use with

opt(cond, 5)

Edit: ker is right, this is only the same if the calculation of the second argument doesn’t fail.

[oli-obk]

that won’t work for ts that can fail like numerator/denominator when denominator is zero