Repository navigation
Tracking issue for Vec::extract_if and LinkedList::extract_if #43244
Description
Feature gate: #![feature(extract_if)] (previously drain_filter)
This is a tracking issue for Vec::extract_if and LinkedList::extract_if, which can be used for random deletes using iterators.
Public API
pub mod alloc {
pub mod vec {
impl<T, A> Vec<T, A>
where
A: Allocator,
{
pub fn extract_if<F>(&mut self, filter: F) -> ExtractIf<'_, T, F, A>
where
F: FnMut(&mut T) -> bool;
}
pub struct ExtractIf<'a, T, F, #[unstable(feature = "allocator_api", issue = "32838")] A = Global>
where
F: FnMut(&mut T) -> bool,
A: Allocator;
impl<T, F, A> Iterator for ExtractIf<'_, T, F, A>
where
F: FnMut(&mut T) -> bool,
A: Allocator;
impl<T, F, A> Drop for ExtractIf<'_, T, F, A>
where
A: Allocator;
impl<T, F, A> Debug for ExtractIf<'_, T, F, A>
where
T: Debug,
F: Debug,
A: Debug + Allocator;
}
pub mod collections {
pub mod linked_list {
impl<T, A> LinkedList<T, A>
where
A: Allocator,
{
pub fn extract_if<F>(&mut self, filter: F) -> ExtractIf<'_, T, F, A>
where
F: FnMut(&mut T) -> bool;
}
pub struct ExtractIf<'a, T, F, #[unstable(feature = "allocator_api", issue = "32838")] A = Global>
where
T: 'a,
F: 'a + FnMut(&mut T) -> bool,
A: Allocator;
impl<T, F, A> Iterator for ExtractIf<'_, T, F, A>
where
F: FnMut(&mut T) -> bool,
A: Allocator;
impl<T, F> Debug for ExtractIf<'_, T, F, Global>
where
T: Debug;
}
}
}Steps / History
- Implementation: Add Vec::drain_filter #43245
- removed drain-on-drop behavior, renamed to extract_if
- Stabilization PR
Unresolved Questions
- What should the method be named?
- Should
extract_ifaccept aRangeargument? - Missing
Send+Syncimpls on linked list's ExtractIf, see comment
See #43244 (comment) for a more detailed summary of open issues.
Metadata
Metadata
Assignees
Labels
Area: `std::collections`Blocker: Implemented in the nightly compiler and unstable.Category: An issue tracking the progress of sth. like the implementation of an RFCLibs issues that are tracked on the team's radar.[DEPRECATED; DO NOT USE]This issue / PR is in PFCP or FCP with a disposition to merge it.The final comment period is finished for this PR / Issue.
Activity
RalfJung commentedon Jul 31, 2017
Related issues:#25477
#34265
Auto merge of #43245 - Gankro:drain-filter, r=sfackler
bluss commentedon Sep 4, 2017
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.
rustonaut commentedon Sep 11, 2017
Is there any chance this will stabilize in some form in the not to far future?
rustonaut commentedon Sep 11, 2017
If the compiler is clever enough to eliminate the bounds checks
in the
drain_filter(.., f)case I would opt for doing this.( And I'm pretty sure you can implement it in a way
which makes the compiler clever eneugh, in the worst
case you could have a "in function specialization",
basically something like
if Type::of::<R>() == Type::of::<RangeFull>() { dont;do;type;checks; return })jonhoo commentedon Sep 22, 2017
I know this is bikeshedding to some extent, but what was the reasoning behind naming this
drain_filterrather thandrain_where? To me, the former implies that the wholeVecwill be drained, but that we also run afilterover the results (when I first saw it, I thought: "how is this not just.drain(..).filter()?"). The former on the other hand indicates that we only drain elements where some condition holds.rustonaut commentedon Sep 23, 2017
No idea, but
drain_wheresounds much better and is much more intuitive.Is there still a chance to change it?
bluss commentedon Sep 23, 2017
.remove_ifhas been a prior suggestion toorustonaut commentedon Sep 23, 2017
I think
drain_wheredoes explains it the best. Like drain it returns values, but it does not drain/remove all values but just such where a given condition is true.remove_ifsounds a lot like a conditional version ofremovewhich just removes a single item by index if a condition is true e.g.letters.remove_if(3, |n| n < 10);removes the letter at index 3 if it's < 10.drain_filteron the other hand is slightly ambiguous, does itdrainthenfilterin a more optimized way (like filter_map) or does if drain so that a iterator is returned comparble to the iteratorfilterwould return,and if so shouldn't it be called
filtered_drainas the filter get logically used before...Gankra commentedon Sep 25, 2017
There is no precedent for using
_whereor_ifanywhere in the standard library.jonhoo commentedon Sep 25, 2017
@gankro is there a precedent for using
_filteranywhere? I also don't know that that is that a reason for not using the less ambiguous terminology? Other places in the standard library already use a variety of suffixes such as_untiland_while.crlf0710 commentedon Oct 23, 2017
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.
253 remaining items
Rollup merge of rust-lang#133265 - the8472:extract-if-ranges, r=cuviper
Rollup merge of rust-lang#137109 - bend-n:knife, r=oli-obk
Unrolled build for rust-lang#137109
Rollup merge of #137109 - bend-n:knife, r=oli-obk
Rollup merge of rust-lang#133265 - the8472:extract-if-ranges, r=cuviper
Rollup merge of rust-lang#137109 - bend-n:knife, r=oli-obk
Rollup merge of rust-lang#137109 - bend-n:knife, r=oli-obk
Rollup merge of rust-lang#135734 - nk9:extract_if-doc-equivalent, r=t…
Unrolled build for rust-lang#135734
Rollup merge of rust-lang#135734 - nk9:extract_if-doc-equivalent, r=t…
rust: macros: simplify code using `feature(extract_if)`
rust: macros: simplify code using `feature(extract_if)`