Tracking issue for bool::then_some

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

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?

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

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

@jplatte

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

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

@c410-f3r

@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).

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,

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.)?
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?

You can call bool::then followed by Option::flatten to get the same effect. But it does make sense to have a fallible version of bool::then

Stabilized; I think this tracking issue can be closed 🙂

Only then got stabilized, then_some is still being tracked.

It might be a good idea to move then_some to a new tracking issue and close this one.

I've updated the title and description. I don't think there's any need to create a new issue: that just causes unnecessary churn.

Does that mean we're still considering stabilizing then_some after all?
I thought we decided that adding then_some was redundant, since then can already do everything then_some can and more.

@slerpyyy

@slerpyyy: yes, see #64260 (comment). There was a desire to see how useful then_some was in practice as a shorthand. This pattern (taking a value vs taking a closure) is already common throughout the standard library.

Closing this one in favour of #80967, so that we'll get a chance to issue a fresh FCP if we decide to in the future.

As an experience report, I've recently found roughly the following code in the wild:

(!is_uppercase)
    .then(|| ())
    .ok_or_else(|| ParseError(ParseErrorKind::Invalid, value.to_string()))

It takes some mental puzzle-solving to figure out whether is_uppercase results in error or not.

Don't think this is actionable in any way, but it's a useful real-world specimen to ponder.

I think that is a good example that not everything is better with combinators :)

I haven't decipered 100% it but I would write this as:

if !is_uppercase {
    return Err(ParseError(...));
}

Personally, I've been using .then() primarily with .filter_map. I think it is a fantasic fit for that.

Agree, I've seen some similar code in the wild. I think that usually .then() is only appropriate in cases where an Option (or Result, via ok_or_else) is actually in play; .then() followed immediately by *_or_else is probably an antipattern (because you're needlessly round-tripping through an Option). I'd love to see a clippy lint to this effect.

Navigation Menu

Repository navigation

Tracking issue for `bool::then_some` #64260

134 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for bool::then_some #64260

Description

Activity

U007D commented on Nov 19, 2019

varkor commented on Nov 19, 2019

jplatte commented on Nov 19, 2019

varkor commented on Nov 19, 2019

c410-f3r commented on Dec 21, 2019

varkor commented on Dec 21, 2019

U007D commented on Jan 26, 2020

RustyYato commented on Jan 26, 2020

134 remaining items

jplatte commented on Dec 28, 2020

CryZe commented on Dec 28, 2020

m-ou-se commented on Dec 28, 2020

varkor commented on Dec 28, 2020

slerpyyy commented on Dec 28, 2020

varkor commented on Dec 30, 2020

KodrAus commented on Jan 13, 2021

matklad commented on Nov 23, 2021

thomaseizinger commented on Nov 23, 2021

Lucretiel commented on Nov 23, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking issue for `bool::then_some` #64260