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

[m-ou-se]

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?

[the8472]

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

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

[m-ou-se]

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 };

[the8472]

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.

[camsteffen]

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.

[m-ou-se]

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.

[m-ou-se]

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.

[jakoschiko]

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

[m-ou-se]

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.

[camsteffen]

FWIW this was attempted in #75298.