-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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::extract_if and LinkedList::extract_if #43244
Comments
Add Vec::drain_filter This implements the API proposed in #43244. So I spent like half a day figuring out how to implement this in some awesome super-optimized unsafe way, which had me very confident this was worth putting into the stdlib. Then I looked at the impl for `retain`, and was like "oh dang". I compared the two and they basically ended up being the same speed. And the `retain` impl probably translates to DoubleEndedIter a lot more cleanly if we ever want that. So now I'm not totally confident this needs to go in the stdlib, but I've got two implementations and an amazingly robust test suite, so I figured I might as well toss it over the fence for discussion.
Maybe this doesn't need to include the kitchen sink, but it could have a range parameter, so that it's like a superset of drain. Any drawbacks to that? I guess adding bounds checking for the range is a drawback, it's another thing that can panic. But drain_filter(.., f) can not. |
Is there any chance this will stabilize in some form in the not to far future? |
If the compiler is clever enough to eliminate the bounds checks ( And I'm pretty sure you can implement it in a way |
I know this is bikeshedding to some extent, but what was the reasoning behind naming this |
No idea, but |
|
I think
|
There is no precedent for using |
The "said equivalent" code in the comment is not correct... you have to minus one from i at the "your code here" site, or bad things happens. |
IMO it's not Again, just from a newbie perspective, the things I would search for if trying to find something to do what this issue proposes would be I actually searched for It seems like a simple function named |
On a separate note, I don't feel as though this should mutate the vector it's called on. It prevents chaining. In an ideal scenario one would want to be able to do something like: vec![
"",
"something",
a_variable,
function_call(),
"etc",
]
.reject(|i| { i.is_empty() })
.join("/") With the current implementation, what it would be joining on would be the rejected values. I'd like to see both an |
You can already do the chaining thing with |
Yes, it's a member of |
Drain is novel terminology because it represented a fourth kind of ownership in Rust that only applies to containers, while also generally being a meaningless distinction in almost any other language (in the absence of move semantics, there is no need to combine iteration and removal into a single ""atomic"" operation). Although drain_filter moves the drain terminology into a space that other languages would care about (since avoiding backshifts is relevant in all languages). |
I came across
|
I still feel as though |
Shouldn't |
Yes |
Add Drop impl for linked_list::DrainFilter This is part of #43244. See #43244 (comment)
I also understand this func in terms of "drain". I think this word should appear in its name somehow. |
drain/extract already conveys a continuous iteration. |
The methods were intentionally renamed because they behave differently compared to |
I wasn't aware of that, thanks. It makes sense to be different then. |
Maybe the history section should be updated to highlight the name change and the reason a bit better |
Is it possible to point to this feature when a user is trying to use the |
…lter` with `extract_if` rust-lang/rust#43244
I'm eagerly anticipating the addition of this feature to the standard library. Could it be stabilized this year? |
Quick question for anyone familiar with the internals of the unstable |
They shouldn't suddenly restart, no. So it most likely is an oversight. |
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: Concerns:
Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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. |
Not necessarily a blocking concern, but can we remove the |
Sure I'll add that to my PR. |
Also another note from the libs-api meeting is that we are still interested in solving more exotic use cases such as Such an API should be proposed as a separate ACP, with inspiration from linked list cursors (#58533) and B-Tree cursors (#107540). |
Resolving the concern since the corresponding work is in progress. @rfcbot resolved vec-needs-a-range-argument |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
Feature gate:
#![feature(extract_if)]
(previouslydrain_filter
)This is a tracking issue for
Vec::extract_if
andLinkedList::extract_if
, which can be used for random deletes using iterators.Public API
Steps / History
Unresolved Questions
extract_if
accept aRange
argument?Send
+Sync
impls on linked list's ExtractIf, see commentSee #43244 (comment) for a more detailed summary of open issues.
The text was updated successfully, but these errors were encountered: