Tracking Issue for Iterator::contains

[yonikremer]

Feature gate: #![feature(iter_contains)]

This is a tracking issue for a method of the Iterator trait that checks whether an iterator contains an item.

A method of the iterator trait to check whether it contains an element.
It goes over all the elements in the iterator and checks if they are in the collection.

Public API

fn contains<Q: ?Sized>(&mut self, item: Q) -> bool
    where
        Q: PartialEq<Self::Item>,
        Self: Sized,

Steps / History

• ACP: Adding the contains method for the iterator trait libs-team#408
• Implementation: Add experimental Iterator::contains #135018
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[tgross35]

@yonikremer is there a ACP proposing this or an implementation PR that you could link?

#![feature(conatins)]

I should think not (check spelling :) and needs to be scoped to something like iterator_contains)

[yonikremer]

@tgross35 No ACP is proposing this. I am implementing the feature now. I will add a pull request very soon.

[tgross35]

You shouldn't really open a tracking issue until there has been an accepted proposal, and there is definitely something to be discussed about the bounds (we aren't very happy with the PartialEq bound in slice contains, using Borrow like HashMap might be better). Please open an ACP, it's an issue template at https://github.com/rust-lang/libs-team/issues.

[yonikremer]

I have filed the issue template: rust-lang/libs-team#408

[zachs18]

cc rust-lang/rfcs#3624, which would be required for stabilizing this without breaking code that calls Itertools::contains without fully qualified syntax.

[yonikremer]

@zachs18 I will rename the function to: has_item and that won't brake any code.

[tgross35]

I think you can keep the function name contains under the gate iterator_contains - it's a better fit, consistent with other APIs (slice, Vec, HashMap, etc), and well known.

We need to resolve supertrait shadowing anyway, there are other itertools methods that we would like to pick up.

[yonikremer]

@tgross35 it looks like the super trait shadowing pull request has been waiting to be merged for over a month. Why? can I help?

[tgross35]

Nothing really to be done there at the moment, it's just waiting on team discussion and for everyone to take the time to read it. A PR adding unstable Iterator::contains is not blocked by this RFC, only stabilization is (Iterator::intersperse is in the same boat).

[yonikremer]

I have the implementation, docs, and tests ready. I need to figure out whether to call it contains/has_item and then I can send a pull request. @tgross35 Should I just rename it to contains and submit a pull request for the unstable feature?

[Amanieu]

You should keep the original name contains. It's consistent with existing practice ([T]::contains) and we have a plan to resolve the conflict with itertools. Only if it turns out that this plan won't work then we will re-visit the naming of unstable iterator methods.