Tracking Issue for bool_to_option

[KodrAus]

Feature gate: #![feature(bool_to_option)]

This is a tracking issue for bool::then_some, a value-receiver version of bool::then, split off from #64260.

Public API

impl bool {
    pub fn then_some<T>(self, t: T) -> Option<T>;
}

Steps / History

• Implementation: Add methods for converting bool to Option<T> #64255
• Final commenting period (FCP)
• Stabilization PR: Stabilize bool::then_some #96628

Unresolved Questions

• Do we actually want this method? There was concern that it didn't really pull its weight compared to bool::then. There was discussion in about this Tracking issue for bool::then_some #64260

[iago-lito]

I personally like bool.then_some(value) better than bool.then(|| value) because it's less circuit in my head (althought I do expect both to produce same machine code). I would also favour it if it's more consistent with the rest of std.

Otherwise, bool.then(|| value) is fine and I could definitely live with that, so the stakes aren't high IMO. What's the overhead of having both methods in std?

[slerpyyy]

I'm in favor of deprecating then_some for the following reasons:

• I still don't like the name
  • Since it is the conceptually simpler version of then, I think it should have the shorter/simpler name of the two functions, similar to and vs and_then, or vs or_else and unwrap_or vs unwrap_or_else and because then is already one word (and we don't want to call it th) this won't be possible.
  • The std crate uses the word then (and else) in function names almost exclusively to imply lazy evaluation (see again and vs and_then). then_some would only be the second function in the entire std crate to break this pattern.
  • The word some makes it sound like there is a then_none or then_ok counterpart to then_some, which does not exist. For the same reason, I believe being exposed to then_some first makes the name of the then function less intuitive and harder to find.
• then can already do everything then_some can do (and more!)
  • Every use of the then_some function can be trivially translated to use then instead, by adding || in front of the argument.
  • then_some can't even be called shorthand for then, because b.then(|| 5) is 2 bytes shorter b.then_some(5).
  • There is no decrease in performance to using then instead of then_some, because the compiler is smart enough to optimize closures away if they're unnecessary (see this comment in the original issue). Depending on how heavy the computation of the argument is, then might even give you a performance benefit, because the computation is skipped entirely if the bool evaluates to false.

[nagisa]

Every use of the then_some function can be trivially translated to use then instead, by adding || in front of the argument.

That wouldn't necessarily have the same semantics. then evaluates the argument, thus executing all of the code necessary to construct the T regardless of the bool's value.

[Boscop]

So instead of cond.then_some(foo()) you'd have to write cond.then({ let v = foo(); move || v })
or write it in multiple lines :/

[iago-lito]

The following two versions are not strictly identical indeed:

#![feature(bool_to_option)]

fn create_value() -> u32 {
    println!("creating");
    16
}

fn main() {
    let cond = false;
    println!("{:?}", cond.then_some(create_value()));
    println!("----");
    println!("{:?}", cond.then(|| create_value())); // or cond.then(create_value)
}

prints

creating
None
----
None

So it's not just a matter of syntax.

Not sure whether this particular behaviour of then_some is useful though.

[x87]

With .then_some I can do the following:

    fn f() -> Option<usize> {
        let x: Option<Vec<u32>> = Some(vec![]);
        true.then_some(x?.len())
    }

how do I rewrite this example using .then?

    fn f() -> Option<usize> {
        let x: Option<Vec<u32>> = Some(vec![]);
        true.then(|| x?.len())
    }

gives an error that a closure should return either a Result or Option.

I can think of an extracting the closure expression into a variable:

    fn f() -> Option<usize> {
        let x: Option<Vec<u32>> = Some(vec![]);
        let len = x?.len();
        true.then(|| len)
    }

But in my opinion the first example with .then_some looks more concise and does not require a block {...}

[jplatte]

how do I rewrite this example using .then? [...]

If you use ? on your Option<Vec<u32>> anyways, might as well do it before assigning to a local:

fn f() -> Option<usize> {
    let x: Vec<u32> = Some(vec![])?;
    true.then(|| x.len())
}

[slerpyyy]

If you insist on eagerly evaluating the value inside the option, you can also make use of Option::filter.

@iago-lito

#![feature(bool_to_option)]

fn create_value() -> u32 {
    println!("creating");
    16
}

fn main() {
    let cond = false;
    println!("{:?}", cond.then_some(create_value()));
    println!("----");
    println!("{:?}", Some(create_value()).filter(|_| cond));
}

@x87

fn f() -> Option<usize> {
    let x: Option<Vec<u32>> = Some(vec![]);
    Some(x?.len()).filter(|_| true)
}

[iago-lito]

@slerpyyy Well, this does work, but it becomes really hard to read IMO. I would argue that this being the only workaround to "eager evaluation" would be a good reason to actually include then_some ;)

Note that I'm still unsure whether "eager evaluation" is useful anyway, has anyone ever needed this?

To summarize my understanding of the advantage of then_some against then so far:

• permits early evaluation (but I'm not sure whether it's useful, is it?)
• permits early return (but @jplatte offered a convincing workaround IMO)
• .. anything else?

[varkor]

I prefer to use then_some than then when possible: needlessly creating a closure feels inelegant, even if in practice it makes no difference to generated code. It is also more consistent with existing APIs. I agree the name is unfortunate, but I don't view this as a reason not to have both. There's no way to make the names consistent with existing APIs now, so we could always go with a shorter name like some that is unrelated to then, which would at least address the length concern. I don't think the two names have to be related: it helps a little with memorisation, but if they're both useful (which in my experience, and others', they are), then it doesn't matter so much.

[slerpyyy]

You're right, this is a function that users want and there is no reason not to add it to the std. I'm still annoyed that after more than a year of discussion about what we want to call these two functions in the original issue, we went with the only combination of names I actively dislike. Yet, I see how having this function with a somewhat unfortunate name is still better than not having this functionality at all.

[coolshaurya]

With regards to naming, I personally think then/then_do would have been ideal, but that ship has sailed.

then_some sounds a bit awkward, but I can't think of something better ¯\_(ツ)_/¯