slice::contains with borrowed data

[RalfJung]

HashSet::contains has the following type to allow e.g. searching in a HashSet<String> with an &str:

pub fn contains<Q: ?Sized>(&self, value: &Q) -> bool where
    T: Borrow<Q>,
    Q: Hash + Eq, 

However, slice::contains does not use Borrow, so to search in an &[String] one has to actually allocate a String:

pub fn contains(&self, x: &T) -> bool where
    T: PartialEq<T>, 

Is there a fundamental reason for this, or is this just an omission?

[Mark-Simulacrum]

I'm fairly certain that this was essentially just a mistake when we implemented it, but we can't change it now as it causes inference failures across the ecosystem. I believe it's been tried multiple times and crater runs are disappointing. It's possible the inference for U: PartialEq or the reverse would also be worse.

[RalfJung]

I feared that might be the case. :/

Would it be reasonable to add a contains_bor or so? It's a kludge, but seems better than having to allocate.

[Mark-Simulacrum]

Probably not worth it -- if you want to skip allocating .iter().any(|e| e == foo) is equivalent to contains.

[RalfJung]

Looking at the SliceContains specialization, I am not sure if that's equally efficient for all types?

At the least, the docs should call out this alternative then.

[Mark-Simulacrum]

Hm, yeah, that might be slower for some cases. I forgot we had specialization internally to optimize for some types. Ideally we'd get around the inference failures somehow, e.g., with a default type param, but that seems unlikely to happen soon :/