Tracking issue for Vec::remove_item

[madseagames]

Implemented in #40325

impl<T: PartialEq> Vec<T> {
    pub fn remove_item(&mut self, item: &T) -> Option<T> { /*…*/ }
}

[clarfonthey]

PR moved to #40325 due to reasons

[clarfonthey]

Comments from original thread:

1. I think that we should add this method to VecDeque too.
2. Is remove_last_item desired?

[madseagames]

@clarcharr for remove_last_item you can simply do vec.remove(vec.len() - 1))

[clarfonthey]

@madseagames I meant specifically a method that searches for the item from the end of the vec instead of the beginning

[oberien]

What do you think about adding remove_swap_item? Just as remove_swap reduces the runtime complexity from O(n) to O(1) compared to remove, remove_swap_item would reduce it from O(n + (n-m)) to O(n).

[clarfonthey]

I like swap_remove_item.

[MarkSwanson]

It would be nice if this was more generic.
let v: Vec = Vec::new();
v.remove_item("s"); <-- fails because &str is not a &String

we really want the remove_item "item: &T" to be "something that we can compare equality with the type in the container". This would let remove_item() walk the T items, compare equality, and remove if equal.

[sfackler]

Seems reasonable to change the signature to fn remove_item<U>(&mut self, item: &U) -> Option<T> where T: PartialEq<U> + ?Sized

[leoyvens]

Reviewing the naming used in method names and the docs, it would seem that iterators yield items while vecs contain elements. Considering that we insert elements then we should also remove elements and the method should be called remove_element. That name is a bit long so I'd propose simply remove_eq. However I wonder if we should favor a more general remove_by, or have both.

fn remove_by<F: FnMut(&T) -> bool>(&mut self, f: F)

[zbraniecki]

Any plan to stabilize this?

[SimonSapin]

This has been in nightly for a year with no issue reported on the method itself. There are proposals for additional methods, but that shouldn’t block this one. Please submit separate PRs or RFCs.

@rfcbot fcp merge

[rfcbot]

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Kimundi
• @SimonSapin
• @alexcrichton
• @aturon
• @dtolnay
• @sfackler
• @withoutboats

Concerns:

• rationale-and-vecdeque resolved by Tracking issue for Vec::remove_item #40062 (comment)

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.