Tracking issue for `bool::then_some`

[varkor]

Tracking issue for the bool::then_some method, which abstract the following pattern:

if some_condition {
    Some(t)
} else {
    None
}

bool:then has previously been stabilised as part of this feature gate: #79299

RFC: rust-lang/rfcs#2757
Implementation PR: #64255

[U007D]

In trying this out, I was puzzled why the eager/lazy argument evaluation versions are then/then_with and not and/and_then, which seems more consistent with established patterns in std?

[varkor]

There's a long discussion in the RFC about the naming. The current names are essentially placeholders.

[jplatte]

As a datapoint, this feature turns out pretty useful in proc macros, and I do think the current naming reads nicely: https://github.com/ruma/ruma-api/commit/cb00188e0371c544c4b8622d5a32731f2f6c54b3

[varkor]

@jplatte: that would be helpful to share on the RFC!

[c410-f3r]

It's been sometime since the PR implementation.
Is there anything preventing stabilization? If not, I can write a stabilization report for this feature.

[varkor]

@c410-f3r: the names were only decided upon quite recently. It was decided that we would wait a few versions before deciding to stabilise: rust-lang/rfcs#2757 (comment).

[U007D]

Just came back to give this a test drive in a library I am working on. If we look at common current established patterns in std:

Option:
map<U, F> whereF: FnOnce(T) -> U and
and_then<U, F> whereF: FnOnce(T) -> Option<U>

Result:
map<U, F> whereF: FnOnce(T) -> U and
and_then<U, F> whereF: FnOnce(T) -> Option<U>

And looking at the current implementation of the bool_to_option feature:

bool:
then_some whereF: FnOnce() -> T

The inconsistency is pretty jarring/unexpected, to my mind. Specifically,

1. for consistency shouldn't bool's F: FnOnce() -> T be called map, and F: FnOnce() -> Option<T> be some then derivative (and_then, then_some, etc.)?
2. shouldn't bool_to_option also provide both an F: FnOnce() -> T and an F: FnOnce() -> Option<T> implementation?

This is not just hypothetical; I am working on a library with a type that has a two-step fallible constructor. The intent is to be able to write something along the lines of:

...
impl Foo {
    fn new() -> Option<Self> {
        step_1_check().and_then(|| step_2_check().map(|| Self { /* ... */ }))
    }
}

but with the current plan developers would still have to resort to writing a custom combinator or pull in an external crate like boolinator for this simple case.

Thoughts?