New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for Vec::remove_item #40062

Open
madseagames opened this Issue Feb 23, 2017 · 19 comments

Comments

Projects
None yet
@madseagames
Contributor

madseagames commented Feb 23, 2017

Implemented in #40325

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

This comment has been minimized.

Show comment
Hide comment
@clarcharr

clarcharr Mar 8, 2017

Contributor

PR moved to #40325 due to reasons

Contributor

clarcharr commented Mar 8, 2017

PR moved to #40325 due to reasons

@clarcharr

This comment has been minimized.

Show comment
Hide comment
@clarcharr

clarcharr Mar 8, 2017

Contributor

Comments from original thread:

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

clarcharr commented Mar 8, 2017

Comments from original thread:

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

This comment has been minimized.

Show comment
Hide comment
@madseagames

madseagames Mar 8, 2017

Contributor

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

Contributor

madseagames commented Mar 8, 2017

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

@clarcharr

This comment has been minimized.

Show comment
Hide comment
@clarcharr

clarcharr Mar 8, 2017

Contributor

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

Contributor

clarcharr commented Mar 8, 2017

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

@oberien

This comment has been minimized.

Show comment
Hide comment
@oberien

oberien Mar 15, 2017

Contributor

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).

Contributor

oberien commented Mar 15, 2017

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).

@clarcharr

This comment has been minimized.

Show comment
Hide comment
@clarcharr

clarcharr Mar 15, 2017

Contributor

I like swap_remove_item.

Contributor

clarcharr commented Mar 15, 2017

I like swap_remove_item.

@MarkSwanson

This comment has been minimized.

Show comment
Hide comment
@MarkSwanson

MarkSwanson Jun 3, 2017

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.

MarkSwanson commented Jun 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Jun 3, 2017

Member

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

Member

sfackler commented Jun 3, 2017

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

@leodasvacas

This comment has been minimized.

Show comment
Hide comment
@leodasvacas

leodasvacas Aug 18, 2017

Contributor

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)
Contributor

leodasvacas commented Aug 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@zbraniecki

zbraniecki Jan 29, 2018

Any plan to stabilize this?

zbraniecki commented Jan 29, 2018

Any plan to stabilize this?

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Mar 17, 2018

Contributor

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

Contributor

SimonSapin commented Mar 17, 2018

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

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Mar 17, 2018

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

Concerns:

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.

rfcbot commented Mar 17, 2018

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

Concerns:

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.

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Mar 17, 2018

Member

Are we switching to a V: PartialEq<T> bound?

Member

sfackler commented Mar 17, 2018

Are we switching to a V: PartialEq<T> bound?

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Mar 17, 2018

Contributor

Oops, sorry I missed that. Yes, let’s.

Contributor

SimonSapin commented Mar 17, 2018

Oops, sorry I missed that. Yes, let’s.

@gnzlbg

This comment has been minimized.

Show comment
Hide comment
@gnzlbg

gnzlbg Mar 18, 2018

Contributor

Again here, as a maintainer of collections that offer the Vec and VecDeque APIs I'd like at least a summary comment explaining what this method does, why this design was followed, alternatives, and addressing the issues mentioned here that have received zero replies:

  • should this method be added to VecDeque?
  • @sfackler :

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

  • @leodasvacas naming issue: why items instead of elements? why remove_items instead of remove_by, etc.
Contributor

gnzlbg commented Mar 18, 2018

Again here, as a maintainer of collections that offer the Vec and VecDeque APIs I'd like at least a summary comment explaining what this method does, why this design was followed, alternatives, and addressing the issues mentioned here that have received zero replies:

  • should this method be added to VecDeque?
  • @sfackler :

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

  • @leodasvacas naming issue: why items instead of elements? why remove_items instead of remove_by, etc.
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 19, 2018

Member

@rfcbot concern rationale-and-vecdeque

Just gonna formally register @gnzlbg's concern above

Member

alexcrichton commented Mar 19, 2018

@rfcbot concern rationale-and-vecdeque

Just gonna formally register @gnzlbg's concern above

@kornelski

This comment has been minimized.

Show comment
Hide comment
@kornelski

kornelski Apr 11, 2018

Contributor

Not an issue with the method per se, but it may need to be very clearly documented that the reference is not supposed to be to an item that is in the Vec already, as it creates impossible borrow-checker conundrum.

Users coming from the C world of pointers but no proper equality comparison, may be confused by this method, e.g. https://users.rust-lang.org/t/difficult-borrowing-situation/16794

The remove_eq name mentioned previously would help.

Contributor

kornelski commented Apr 11, 2018

Not an issue with the method per se, but it may need to be very clearly documented that the reference is not supposed to be to an item that is in the Vec already, as it creates impossible borrow-checker conundrum.

Users coming from the C world of pointers but no proper equality comparison, may be confused by this method, e.g. https://users.rust-lang.org/t/difficult-borrowing-situation/16794

The remove_eq name mentioned previously would help.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton May 17, 2018

Member

@SimonSapin as the proposer for FCP, do you have thoughts on @gnzlbg's concern?

Member

alexcrichton commented May 17, 2018

@SimonSapin as the proposer for FCP, do you have thoughts on @gnzlbg's concern?

@droundy

This comment has been minimized.

Show comment
Hide comment
@droundy

droundy Sep 3, 2018

Contributor

My thinking is that the remove_by suggested by @leodasvacas would sidestep most of the issues here.

Contributor

droundy commented Sep 3, 2018

My thinking is that the remove_by suggested by @leodasvacas would sidestep most of the issues here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment