Tracking issue for Option::contains and Result::contains

[Centril]

This is a tracking issue for Option::contains and Result::contains.

The implementations are as follows:

    pub fn contains(&self, x: &T) -> bool where T: PartialEq {
        match self {
            Some(y) => y == x,
            None => false,
        }
    }

    pub fn contains(&self, x: &T) -> bool where T: PartialEq {
        match self {
            Ok(y) => y == x,
            Err(_) => false,
        }
    }
``

[Mark-Simulacrum]

Should we update the signatures to fn contains<U>(&self, x: &U) -> bool where T: PartialEq<U>?

[Centril]

@Mark-Simulacrum That seems like a good idea -- type inference should be driven by x in any case. Let's do that in the PR.

[timvermeulen]

Looks like slice/Vec/VecDeque/LinkedList and possibly others have a contains method that could benefit in the same way.

[soc]

@Mark-Simulacrum I didn't do that because I checked the collections first, and they were all invariant. Shall I change this for Option and Result only?

[Mark-Simulacrum]

We usually can't change preexisting APIs due to inference breakage, but since this is new, we should be able to be general.

[frewsxcv]

Are these functionally equivalent?

    pub fn contains(&self, x: &T) -> bool where T: PartialEq {
        match self {
            Some(y) => y == x,
            None => false,
        }
    }

    pub fn contains(&self, x: &T) -> bool where T: PartialEq {
        self.as_ref() == Some(x)
    }

[soc]

@frewsxcv Not quite, due to the requested variance changes.

[czipperz]

What does that mean @soc?

[soc]

@czipperz The implementation is:

// Option
pub fn contains<U>(&self, x: &U) -> bool where U: PartialEq<T> {
    match self {
        Some(y) => x == y,
        None => false,
    }
}

// Result
pub fn contains<U>(&self, x: &U) -> bool where U: PartialEq<T> {
    match self {
        Ok(y) => x == y,
        Err(_) => false
    }
}

pub fn contains_err<F>(&self, f: &F) -> bool where F: PartialEq<E> {
    match self {
        Ok(_) => false,
        Err(e) => f == e
    }
}

The argument doesn't have to be of the same type as the value inside option/result, only that it knows how to compare itself to it. I. e. the operation is not invariant on the contained type, it allows an arbitrary type.

[czipperz]

So there's no implementation of PartialEq<Option<U>> for Option<T> where U: PartialEq<T>?

[timvermeulen]

There is indeed not, see #20063.

[dtolnay]

These methods are way too high up in the docs on both the Option and Result rustdoc. Would someone be able to send a PR to move these a lot further down? For example stuff like ok and map and and_then should all be featured higher than contains.

[sinistersnare]

What is the status on this? I would love to use these in stable.

[xkr47]

Assume you have a function getFoo() returning Option<String> then it might be misleading if you do getFoo().contains("bar") since it looks like it checks for a substring when it in fact checks for an exact match. Would some other name perhaps be more clear?

[sinistersnare]

how about contains_in or map_contains?

[soc]

option.contains_in("foo") reads weird. You could of course pick something else entirely different, like option.has("foo") or option.includes("foo").

But in the end, Rust is a typed language, so we should not be scared that much about confusion, because the types tell us which contains method is used.

[camsteffen]

Naming bikeshed. Sorry if this is the wrong place.

How about the names eq_some, eq_ok and eq_err? Or maybe only using those names for Result? I get that contains is consistent with containers, but that analogy weakens especially with Result.

[Amanieu]

#108095 argues that this should be removed in favor of is_some_with (#93050) and I agree. That API is more flexible than contains and has a better name.

@rfcbot fcp close

[rfcbot]

Team member @Amanieu has proposed to close this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[BrianLondon]

My anecdotal experience with Scala, which has an Option[T] with both contains(t: T): bool and exists(t: T => bool): bool the later of which is equivalent to the proposed is_some_and, is that use of contains is far more common. I don't know enough about the compiler internals to speak to what performance penalty comes from wrapping the equality check in the closure, but if any, I'd be concerned about the added overhead.

[soc]

@BrianLondon To avoid any disappointment, please refer to

I wouldn't suggest throwing around your experience working on Scala as much as you do.

If you just want to carbon copy the ideology of Scala into Rust, and are not interested in improving on the language, I suggest you go back and work on Scala

Please keep in mind that, while your experience in Scala may be very good with applying Scala ideology to Scala problems, Rust might not fit in the same corner.

to learn about the community's preferences on this topic.

Thanks!

[BrianLondon]

Thanks @soc, is there a document you're quoting? If so can you link to the original please? I'd like to read the rest of it.

I think you're making some incorrect assumptions about my motivations. To be clear I am not suggesting a carbon copy of Scala, or even proposing to bring any particular Scala idiom into Rust. I am categorically not, for example, saying is_some_and should be renamed exists or something. What I am saying is that I expect is_some_and(|x| x == target) to be the predominant way it's used, and I'm asking whether there is a performance cost to running the comparison through the closure.

[BurntSushi]

@BrianLondon soc does not speak for the community, and as a member of libs-api, I am generally happy to hear about experiences from other programming languages. (Although I do always, regardless of language, cast a skeptical eye because it can be tricky to analogize different environments. But I think your experience is relevant here.)

[camsteffen]

@BrianLondon, @soc is just quoting earlier comments in this thread where they got into a squabble with another individual, so no need to worry about that. Generally the community is welcoming to different perspectives.

[AaronKutch]

I personally think that Option::contains makes sense and should be a thing in parallel to is_some_and. Result::contains, however, will result in a cognitive ambiguity in Result<T, T> cases (I have used these multiple times in practice). For Result there should just be is_ok_and and is_err_and (edit: or also maybe ok_contains and err_contains?)

[khionu]

As the moderator who handled the referred situation, I want to confirm that Brian's original comment from yesterday was not of the same problems. What was done well was that Brian noted that their experience was anecdotal, not treating their views as authoritative, and they also softened their contribution by acknowledging what they weren't aware of. This makes a world of difference in how one brings outside experience to Rust.

[rfcbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[soc]

@Centril methods have been removed, this issue can be closed now.

[univerz]

i tried to remove .contains(&y), but rewriting it to .as_ref().is_some_and(|x| x == &y) annoyed me so much i had to re/introduce Contains trait into my stdx.rs file

[bjorn]

@univerz As per above commit one could also replace by iter().any(...), but it is only a little bit shorter so not any less annoying. I'm sad about the outcome of this issue. :-(

[soc]

@univerz Perhaps option-ext can be of use to you!