Add slice::contains_ref to supplement slice::contains

[poliorcetics]

Fixes #42671.

This adds the last function proposed in #42671:

pub fn contains_ref<U>(&self, x: &U) -> bool where T: PartialEq<U>, U: ?Sized { /* ... */ }

I simply used self.iter().any(|e| e == x) as a first implementation, I don't know if there is a more optimised version possible.

I put an unstable flag, should I create a tracking issue for this ? I don't know if this is a "big enough" feature for it ?

@rustbot modify labels: A-collections,C-enhancement,T-doc,T-libs

[rust-highfive]

r? @sfackler

(rust_highfive has picked a reviewer for you, use r? to override)

[Muirrum]

@sfackler This is a triage bump.

[bors]

☔ The latest upstream changes (presumably #73265) made this pull request unmergeable. Please resolve the merge conflicts.

[Dylan-DPC-zz]

r? @scottmcm

[scottmcm]

Hmm, this is one of those things that's almost all API decisions, so while I have no technical issues with the code, I don't feel like this is something I can approve myself, even for unstable.

So ping @rust-lang/libs, as I didn't notice any comments from them about this approach in #42671, and marking waiting-on-team.

A handful of ponderings:

• Is this the right name? [T]::contains also takes a ref, so it's not obvious to me that contains_ref is the right distinguisher.
• Is the PartialEq<Other> approach the best one, given that it's a new method without the inference-breakage restrictions of the existing contains? For example, is there a way this can support simpler callers, like allowing .contains_bikeshed(0) instead of needing the caller to pass &0?

[scottmcm]

If this gets a "seems plausible" from libs, please do create a tracking issue for this: https://github.com/rust-lang/rust/issues/new?labels=C-tracking-issue&template=tracking_issue.md&title=Tracking+Issue+for+slice::contains_ref

[poliorcetics]

I'll remember it !

[poliorcetics]

Does this example does what you want @scottmcm ?

struct MyNum(u8);

struct MyOtherNum(u8);

impl PartialEq<u8> for MyNum {
    fn eq(&self, other: &u8) -> bool {
        self.0 == *other
    }
}

impl PartialEq<MyOtherNum> for MyNum {
    fn eq(&self, other: &MyOtherNum) -> bool {
        self.0 == other.0
    }
}

impl PartialEq<&u8> for MyNum {
    fn eq(&self, other: &&u8) -> bool {
        self.0 == **other
    }
}

impl PartialEq<&MyOtherNum> for MyNum {
    fn eq(&self, other: &&MyOtherNum) -> bool {
        self.0 == other.0
    }
}

// Same functionality as the `contains_ref` method in the PR.
fn search<T, U>(sl: &[T], other: U) -> bool
                            //   ^ takes `U` instead of `&U`
where
    T: PartialEq<U>,
    // No `U: ?Sized` here
{
    sl.iter().any(|e| e == &other)
                            // ^ uses a `&` here
}

fn main() {
    let v = [String::from("Hello"), String::from("world")];
    assert!(search(&v, "Hello"));
    assert!(!search(&v, "Rust"));

    let v = [0, 2];
    assert!(search(&v, 0));
    assert!(!search(&v, 1));

    let v = [MyNum(0), MyNum(2)];
    assert!(search(&v, 0));
    assert!(!search(&v, 1));
    assert!(search(&v, &0));
    assert!(!search(&v, &1));
    assert!(search(&v, MyOtherNum(0)));
    assert!(!search(&v, MyOtherNum(2)));
    assert!(search(&v, &MyOtherNum(0)));
    assert!(!search(&v, &MyOtherNum(2)));
}

It needs the implementation for u8 and &u8 which I find bothering because it means a function cannot call search like this:

fn do_something<T, U>(sl: &[T], other: &U)
where
    T: PartialEq<U>,
{
    search(sl, other);
            // ^^^^^ expected type parameter `U`, found `&U`
            // but `U` is not `Copy`.

    // ...
}

[withoutboats]

I don't think the name contains_ref captures the distinction from contains that is relevant here.

[poliorcetics]

I agree with that, I just don't have any idea for a better name.

[LukasKalbertodt]

I also think the name is problematic, but also can't think of a better one. Unless we find a nice name, I would prefer not to add this API: v.iter().any(|x| x == "needle") is already pretty concise and is only marginally less readable/understandable than v.contains("needled") in my opinion. I don't think it's worth expanding the API in this case.

[poliorcetics]

Feel free to close if there is no idea for a better name.

It may be worth closing the original issue too in this case since the v.iter().any(|x| x == "needle") workaround is already explained in the documentation for contains on stable.

[crlf0710]

Triage: What's the status here? Should this be closed?