Add Vec::contains_ref which is worse for inference but less restrictive than Vec::contains

[Istvan91]

Using Vec::contains currently only works if the contains parameter is of the same &Type as the Vector elements. This means the parameter must be converted to the vec-item-type even though it is comparable with the type in the first place.

e.g. following code does not work, even though impl<'a, 'b> PartialEq<str> for String exists:

fn main() {
    let mut v: Vec<String> = Vec::new();
    v.contains("mystring");
}

The Error:

error[E0308]: mismatched types
 --> <anon>:3:16
  |
3 |     v.contains("mystring");
  |                ^^^^^^^^^^ expected struct `std::string::String`, found str
  |
  = note: expected type `&std::string::String`
             found type `&'static str`

I'd be better if Vec::contains had definition like:
fn contains<U>(&self, value: &U) where T: PartialEq<U>, U: ?Sized

[kennytm]

You could use v.iter().any(|x| x == "mystring") as a workaround, you don't need to convert the &str to String.

[Istvan91]

I'm aware of this workaround, but isn't that what "contains" should be in the first place?

[kennytm]

There was an attempt to fix this in #43020 but it has caused some major inference failure.

[briansmith]

Is the alternative mentioned in #43020 (comment) any better with respect to the inference failure?

[dtolnay]

Tagging C-feature-accepted to follow up on the approach in #43020 (comment). Please submit a PR with an implementation and tests. We will need to confirm that this causes less breakage than the original Borrow-based approach.

[varkor]

This was attempted using the other approach in #46934. Unfortunately, it too causes too much breakage in downstream crates. Even though this API change would be significantly nicer, it doesn't seem plausible unless this breakage is acceptable (maybe for a later epoch).

[varkor]

Note that the problems mentioned here are the same as those in #20063.