Tracking Issue for Option::is_some_and and Result::is_{ok,err}_and

Feature gate: #![feature(is_some_and)]

This is a tracking issue for Option::is_some_and, Result::is_ok_and and Result::is_err_and.

Public API

impl<T> Option<T> {
    pub fn is_some_and(self, f: impl FnOnce(T) -> bool) -> bool;
}

impl<T, E> Result<T, E> {
    pub fn is_ok_and(self, f: impl FnOnce(T) -> bool) -> bool;
    pub fn is_err_and(self, f: impl FnOnce(E) -> bool) -> bool;
}

Steps / History

Lots of discussion and bikeshedding starting here: Tracking issue for Option::contains and Result::contains #62358 (comment)
Implementation: Add Option::is_some_with and Result::is_{ok,err}_with #93051
Rename: Rename is_{some,ok,err}_with to is_{some,ok,err}_and. #94765
Take self by value: Change is_some_and to take by value #98354
Final comment period (FCP)
Stabilization PR: Stabilize is_some_and #110019

Unresolved Questions

Naming. Alternatives:
- is_some_with / is_ok_with / is_err_with
- ➡️ is_some_and / is_ok_and / is_err_and
  - See Tracking Issue for Option::is_some_and and Result::is_{ok,err}_and #93050 (comment) and Tracking Issue for Option::is_some_and and Result::is_{ok,err}_and #93050 (comment)
- contains / contains_err
- and_is / and_err_is
- is
- has
Take self or &self?

What are the use-cases? And won't that largely be covered by if-let chains?

if let Some(foo) = opt && foo > bar {
   
}

Lots of functions on Option and Result are already 'covered' by match or if let, but it's still very useful to have methods for the most common cases. It makes things more readable and less verbose, and also easier to write (especially with auto completion).

let deadline_passed = optional_deadline.is_some_with(|d| d < now);

let deadline_passed = matches!(optional_deadline, Some(d) if d < now);

let deadline_passed = if let Some(d) = optional_deadline && d < now { true } else { false };

I assume deadline_passedwould then flow into another if in which case one could do an if-let-chain (once that's stable) directly rather than having a separate variable for that. I mean as I understand it the purpose of if-let-chain is to make such towers of conditionals more readable.
Maybe it's useful inside a filter closure? But then one could flatten() first and then filter instead.

I think a code example with a bit more context that would benefit from this and wouldn't be replaced by if-let-chain in the future would be helpful.

Naming. Alternatives:

Or maybe just is? Assuming we want to spend our small budget of meaningful two-letter words on this.
But I like is_some_and since it is consistent with the way the if is written.

is or any name ending in "is" will not flow well with function names in the argument: opt.and_is(char::is_lowercase), dog.and_is(Dog::has_a_bone), etc.

is_some_and flows better. I would consider the shorter some_and as well.

I assume deadline_passedwould then flow into another if in which case one could do an if-let-chain (once that's stable) directly rather than having a separate variable for that.

This example about a deadline: Option<Instant> comes directly from code I worked on recently. Checking some condition on a Some is a pattern that occurs reguarly there. In some cases it's just used in an if directly, but in many cases the value is stored in some struct first, or used by multiple ifs, or passed to a function, serialized and sent over a socket, etc. In some cases it's only used in a single if, but part of a much more complicated condition. Various parts of that condition are first assigned to named bools to keep things clear. (Just like why people use matches!() rather than a match or if let in some situations. Or x.is_some() rather than if let Some(_) = x. Or x.then() instead of if x {}. And so on.)

Or maybe just is?

I've added is and has to the alternatives.

There are 117 cases of .map_or(false, in the compiler/ directory in the rust repository. Most of them are probably good examples of use cases for these methods.

The name is_some_and would allow us to add its counterpart is_none_or in the future.

is_some_and

After thinking about it a bit more, I like this name. It very clearly states that it first checks is_some, and then also checks a condition afterwards.

FWIW this was attempted in #75298.

Rollup merge of rust-lang#94765 - m-ou-se:is-some-and, r=Dylan-DPC

Use Rust nightly in CI

As someone who finds map_or both overly verbose for this (I need this version far more than the general case of map_or) and generally unpleasant (due to argument order not matching the name, although I 100% understand that decision even if I don't love it) I would be thrilled for this.

I think the worry about overlap with if/let is valid but for filtering and other combinators this composes really well (having played with it some now)

Also +1 to is_some_and for the name, very much a fan

Is this just waiting for somebody to create a stabilization PR? I can probably do that if so.

Is this just waiting for somebody to create a stabilization PR? I can probably do that if so.

Yes. Feel free to go ahead.

The description of this API in this tracking issue and in #110019 say that the closure takes &T but the implementation has the closure taking T.

We had a second FCP to change the closure to take T, but it seems that we forgot to update the issue description. I've just updated it.

I totally forgot about all that.. Well I guess I will live with it. The draft PR to show that it made is_some_and calls "nicer" unfortunately didn't show any places where taking ownership of of the inner value was necessary, but maybe there are a few and it would probably be pretty annoying for some people for the combinator to not be applicable therethr same way I find the extra as_ref annoying where it is needed..

Auto merge of rust-lang#110019 - jplatte:jplatte/stabilize-is-some-an…

Replace unstable library feature

Well, I don't know if these functions are really that essential. These checks can be made in several different ways.

let data = Some("foo");

if data == Some("foo") {
    //...
}
if data.is_some_and(|inner| inner == "foo") {
    //...
}
if let Some(inner) = data && inner == "foo" {
    //...
}
if matches!(data, Some(inner) if inner == "foo") {
    //...
}

The first might only be desirable in some cases, but the third one with let-chains #53667 is a little bit more legible, in my opinion.

In which version should we expect this feature? I thought it was going to be in 1.70.0, but apparently not.

It is in 1.70.0 (see https://blog.rust-lang.org/2023/06/01/Rust-1.70.0.html)

fix: avoid is_some_with

Navigation Menu

Repository navigation

Tracking Issue for Option::is_some_and and Result::is_{ok,err}_and #93050

Public API

Steps / History

Unresolved Questions

94 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for Option::is_some_and and Result::is_{ok,err}_and #93050

Description

Public API

Steps / History

Unresolved Questions

Activity

the8472 commented on Jan 18, 2022

m-ou-se commented on Jan 18, 2022

the8472 commented on Jan 18, 2022

camsteffen commented on Jan 18, 2022

m-ou-se commented on Jan 18, 2022

m-ou-se commented on Jan 18, 2022

jakoschiko commented on Jan 19, 2022

m-ou-se commented on Jan 22, 2022

camsteffen commented on Mar 7, 2022

jam1garner commented on May 4, 2022

94 remaining items

jplatte commented on Apr 5, 2023

Amanieu commented on Apr 5, 2023

asquared31415 commented on Apr 6, 2023

Amanieu commented on Apr 6, 2023

jplatte commented on Apr 7, 2023

wrenger commented on May 19, 2023

tnblumer commented on Jun 5, 2023

RalfJung commented on Jun 6, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions