Skip to content

Mapping booleans to Option #50523

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jonhoo opened this issue May 8, 2018 · 5 comments
Closed

Mapping booleans to Option #50523

jonhoo opened this issue May 8, 2018 · 5 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@jonhoo
Copy link
Contributor

jonhoo commented May 8, 2018

In a decent number of situations, I end up finding myself writing code like:

if foo {
    Some(bar)
} else {
    None
}

This happens especially in closures passed to Iterator::filter_map, but I also frequently find that I want this in .and_then (e.g., on futures). For cases like these, it'd be very handy to have a concise way of turning booleans into Options. For example:

impl bool {
    fn map_true<T>(&self, on_true: T) -> Option<T> { if *self { Some(on_true) } else { None }}
    fn map_false<T>(&self, on_true: T) -> Option<T> { if *self { None } else { Some(on_true) }}
}

There could also be closure variants of this for cases where the T is expensive to construct, but in my experience those cases are rarer. That would let the code above become:

foo.map_true(bar)

The name could of course be bikeshed (if_true?), but I think this is a pretty versatile and useful shorthand!

@Reconcyl
Copy link

Reconcyl commented May 8, 2018

Are you looking for Option::filter()? It's currently unstable so you can only use it with #[feature(option_filter)] on nightly, but it seems like it's what you want.

@killercup
Copy link
Member

You could probably use boolinator to write foo.as_some(bar)

@varkor
Copy link
Member

varkor commented May 8, 2018

For what it's worth, I've seen this question come up multiple times in the past (and I know I've made use of the pattern before). Perhaps it is worth considering adding it to bool's implementation.

Edit: Ah, I knew I had seen it recently. I forgot it was in the RFCs repository rather than this one.

@kennytm
Copy link
Member

kennytm commented May 8, 2018

Please check rust-lang/rfcs#2180.

@kennytm kennytm added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-feature-request Category: A feature request, i.e: not implemented / a PR. labels May 8, 2018
@jonhoo
Copy link
Contributor Author

jonhoo commented May 8, 2018

@ScratchMan544 Option::filter isn't quite the same, as it is Option<T> -> bool -> Option<T>, whereas what I want is bool -> T -> Option<T>. The RFC @kennytm links is exactly this (though I think it should also have a variant for false)! I guess I'll close in favor of that.

@jonhoo jonhoo closed this as completed May 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants