|
| 1 | +- Feature Name: contains_method_for_various_collections |
| 2 | +- Start Date: 2016-03-16 |
| 3 | +- RFC PR: (leave this empty) |
| 4 | +- Rust Issue: (leave this empty) |
| 5 | + |
| 6 | +# Summary |
| 7 | +[summary]: #summary |
| 8 | + |
| 9 | +Add a `contains` method to `VecDeque` and `LinkedList` that checks if the |
| 10 | +collection contains a given item. |
| 11 | + |
| 12 | +# Motivation |
| 13 | +[motivation]: #motivation |
| 14 | + |
| 15 | +A `contains` method exists for the slice type `[T]` and for `Vec` through |
| 16 | +`Deref`, but there is no easy way to check if a `VecDeque` or `LinkedList` |
| 17 | +contains a specific item. Currently, the shortest way to do it is something |
| 18 | +like: |
| 19 | + |
| 20 | +```rust |
| 21 | +vec_deque.iter().any(|e| e == item) |
| 22 | +``` |
| 23 | + |
| 24 | +While this is not insanely verbose, a `contains` method has the following |
| 25 | +advantages: |
| 26 | + |
| 27 | +- the name `contains` expresses the programmer's intent... |
| 28 | +- ... and thus is more idiomatic |
| 29 | +- it's as short as it can get |
| 30 | +- programmers that are used to call `contains` on a `Vec` are confused by the |
| 31 | + non-existence of the method for `VecDeque` or `LinkedList` |
| 32 | + |
| 33 | +# Detailed design |
| 34 | +[design]: #detailed-design |
| 35 | + |
| 36 | +Add the following method to `std::collections::VecDeque`: |
| 37 | + |
| 38 | +```rust |
| 39 | +impl<T> VecDeque<T> { |
| 40 | + /// Returns `true` if the `VecDeque` contains an element equal to the |
| 41 | + /// given value. |
| 42 | + pub fn contains(&self, x: &T) -> bool |
| 43 | + where T: PartialEq<T> |
| 44 | + { |
| 45 | + // implementation with a result equivalent to the result |
| 46 | + // of `self.iter().any(|e| e == x)` |
| 47 | + } |
| 48 | +} |
| 49 | +``` |
| 50 | + |
| 51 | +Add the following method to `std::collections::LinkedList`: |
| 52 | + |
| 53 | +```rust |
| 54 | +impl<T> LinkedList<T> { |
| 55 | + /// Returns `true` if the `LinkedList` contains an element equal to the |
| 56 | + /// given value. |
| 57 | + pub fn contains(&self, x: &T) -> bool |
| 58 | + where T: PartialEq<T> |
| 59 | + { |
| 60 | + // implementation with a result equivalent to the result |
| 61 | + // of `self.iter().any(|e| e == x)` |
| 62 | + } |
| 63 | +} |
| 64 | +``` |
| 65 | + |
| 66 | +The new methods should probably be marked as unstable initially and be |
| 67 | +stabilized later. |
| 68 | + |
| 69 | +# Drawbacks |
| 70 | +[drawbacks]: #drawbacks |
| 71 | + |
| 72 | +Obviously more methods increase the complexity of the standard library, but in |
| 73 | +case of this RFC the increase is rather tiny. |
| 74 | + |
| 75 | +While `VecDeque::contains` should be (nearly) as fast as `[T]::contains`, |
| 76 | +`LinkedList::contains` will probably be much slower due to the cache |
| 77 | +inefficient nature of a linked list. Offering a method that is short to |
| 78 | +write and convenient to use could lead to excessive use of said method |
| 79 | +without knowing about the problems mentioned above. |
| 80 | + |
| 81 | +# Alternatives |
| 82 | +[alternatives]: #alternatives |
| 83 | + |
| 84 | +There are a few alternatives: |
| 85 | + |
| 86 | +- add `VecDeque::contains` only and do not add `LinkedList::contains` |
| 87 | +- do nothing, because -- technically -- the same functionality is offered |
| 88 | + through iterators |
| 89 | +- also add `BinaryHeap::contains`, since it could be convenient for some use |
| 90 | + cases, too |
| 91 | + |
| 92 | +# Unresolved questions |
| 93 | +[unresolved]: #unresolved-questions |
| 94 | + |
| 95 | +None so far. |
0 commit comments