-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 {BTreeMap,BTreeSet}::extract_if #70530
Comments
Is there another issue for adding these to HashSet and HashMap? |
That is #59618. |
I stumbled upon this issue from the docs and I must say that I'm a bit confused: I wanted to replace a HashMap with a BTreeMap in my code, but then I noticed that it didn't have a As far as I can tell isn't this method the same thing as HashMap's Looking at the APIs of BTreeMap, Vec and HashMap I find the following methods that all deal with filtering the contents of the collection:
LinkedList has I genuinely don't get the logic behind these choices of mutability and naming. In particular I really think that the APIs of |
Oh, I noticed an obvious difference between retain and drain_filter: the later returns an iterator. So now I understand the need for both, but I'm still surprised by the lack of consistency between collections when it comes to mutability and the lack of |
When I first looked into it, I remember a
If you really do, please explain, but I think you mean you understand why someone made |
I think if we could replace |
Right, I meant that I understand why I also found this issue in the meantime: #59618 so apparently HashMap is going to get a In the meantime it's a real hard scratcher, for me at least. |
For the status of |
Thank you @mbrubeck, this was the context I lacked. |
I submitted #79026 to add |
I think |
Note that this (nightly only) |
Implement BTreeMap::retain and BTreeSet::retain Adds new methods `BTreeMap::retain` and `BTreeSet::retain`. These are implemented on top of `drain_filter` (rust-lang#70530). The API of these methods is identical to `HashMap::retain` and `HashSet::retain`, which were implemented in rust-lang#39560 and stabilized in rust-lang#36648. The docs and tests are also copied from HashMap/HashSet. The new methods are unstable, behind the `btree_retain` feature gate, with tracking issue rust-lang#79025. See also rust-lang/rfcs#1338.
Implement BTreeMap::retain and BTreeSet::retain Adds new methods `BTreeMap::retain` and `BTreeSet::retain`. These are implemented on top of `drain_filter` (rust-lang#70530). The API of these methods is identical to `HashMap::retain` and `HashSet::retain`, which were implemented in rust-lang#39560 and stabilized in rust-lang#36648. The docs and tests are also copied from HashMap/HashSet. The new methods are unstable, behind the `btree_retain` feature gate, with tracking issue rust-lang#79025. See also rust-lang/rfcs#1338.
Implement BTreeMap::retain and BTreeSet::retain Adds new methods `BTreeMap::retain` and `BTreeSet::retain`. These are implemented on top of `drain_filter` (rust-lang#70530). The API of these methods is identical to `HashMap::retain` and `HashSet::retain`, which were implemented in rust-lang#39560 and stabilized in rust-lang#36648. The docs and tests are also copied from HashMap/HashSet. The new methods are unstable, behind the `btree_retain` feature gate, with tracking issue rust-lang#79025. See also rust-lang/rfcs#1338.
As it is now the documentation makes no claims about the order of the events returned from the iterator. Is this intended? having this iterator return in sorted order, or even returning a double ended iterator similar to range could be pretty useful. |
It's not intended not to be made, this claim… I mean, I forgot to mention that, because it's guaranteed to come in ascending order. PS ⇒ #81434 |
it's certainly worth documenting that, but I also think it's worth making this into a double ended iterator. |
It's definitely not easy to make |
I just came across a use case for this method but found it could not handle the case where I need to run my predicate function on the map in reversed order. There are work arounds to this problem, but thought I'd notate potential pain pointers of users. |
I've just had a use-case for something like this, but I needed to drain and filter a specific range of keys (remove certain values that are after a given key in the btreemap). |
+1 for @kornelski I most definitely have a use-case for a drain with range in btreemap |
I also use this to remove all entries within a specific range. I probably would would not need |
For the same reasons this is problematic in Vec and LinkedLists this is also problematic on the BTree collections. |
What's the status of this feature? |
Don't drain-on-drop in DrainFilter impls of various collections. This removes drain-on-drop behavior from various unstable DrainFilter impls (not yet for HashSet/Map) because that behavior [is problematic](rust-lang#43244 (comment)) (because it can lead to panic-in-drop when user closures panic) and may become forbidden if [this draft RFC passes](rust-lang/rfcs#3288). closes rust-lang#101122 [ACP](rust-lang/libs-team#136) affected tracking issues * rust-lang#43244 * rust-lang#70530 * rust-lang#59618 Related hashbrown update: rust-lang/hashbrown#374
This feature stopped working for me with the newest nightly version as of 2023-06-16. |
The feature was renamed in #104455. |
Thanks! After replacing "btree_drain_filter" with "btree_extract_if" and "drain_filter" with "extract_if" the code compiles as before. |
sync w/ upstream References: * rust-lang/rust#104455 * rust-lang/rust#70530 Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
sync w/ upstream References: * rust-lang/rust#104455 * rust-lang/rust#70530 Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The // BTreeMap version
pub struct ExtractIf<'a, K, V, F, A: Allocator + Clone = Global> where
F: 'a + FnMut(&K, &mut V) -> bool,
Edit: Eh, that was a bad example since it type-erased The The same is probably also true for Inspired by this conversation. |
We discussed this in the libs-api meeting today. As with |
This is a tracking issue for the Implementation of a
extract_if
method onBTreeMap
andBTreeSet
, similar to the one in LinkedList and in Vec (#43244).The feature gate for the issue is
#![feature(btree_extract_if)]
(previouslybtree_drain_filter
)About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
Ord
bound: efficient for simple and common cases, but falling back on a coarse restart after complicated removals.Possibly adjust the underlying tree representation (usingCell
s).Ord
bound, tracking every adjustmentUnresolved Questions
Ord
bound ondrain_filter
(that is currently not required)?Vec::drain_filter
andLinkedList::drain_filter
provide, as I tried to discuss in Audit liballoc for leaks inDrop
impls when user destructor panics #67290?Implementation history
Ord
bound onDrainFilter
(not ondrain_filter
) (Remove the Ord bound that was plaguing drain_filter #70843)BTreeMap
(Keep track of position when deleting from a BTreeMap #70795)drain
andretain
(BTreeMap/BTreeSet drain & retain #66747)The text was updated successfully, but these errors were encountered: