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.