Tracking issue for HashMap::extract_if and HashSet::extract_if

[DutchGhost]

The feature gate for the issue is #![feature(hash_extract_if)] (previously hash_drain_filter)

Currently only Vec and LinkedList have a drain_filter method, while other collections such as HashMap and HashSet do not.

This means that currently, removing items from a collection, and getting ownership of those items is fairly...unidiomatic and cumbersome.

For references, see rust-lang/rfcs#2140

Implementation History

• Add drain_filter method to HashMap and HashSet #76458
• removed drain-on-drop behavior, renamed to extract_if
  • Don't drain-on-drop in DrainFilter impls of various collections. #104455
  • Remove drain-on-drop behavior from various DrainFilter iterators libs-team#136

[hellow554]

Related #42849

[mbrubeck]

This may be easy to implement since drain_filter was added to the underlying hashbrown types in rust-lang/hashbrown#135 and rust-lang/hashbrown#179. (Requires hashbrown 0.8.1 or later; see #70052.)

[mbrubeck]

I have implemented this on a branch, but it will need to wait for a new release of the hashbrown crate because it depends on rust-lang/hashbrown#185, rust-lang/hashbrown#187, and rust-lang/hashbrown#188:

master...mbrubeck:hash_drain_filter

[mbrubeck]

This is now implemented in nightly behind the unstable hash_drain_filter feature:

• https://doc.rust-lang.org/nightly/std/collections/struct.HashMap.html#method.drain_filter
• https://doc.rust-lang.org/nightly/std/collections/struct.HashSet.html#method.drain_filter

[benesch]

Any reason not to stabilize this @mbrubeck?

[mbrubeck]

There are some open questions about naming and API design; see the summary in #43244 (comment) for some details.

[OfekShochat]

when do you estimate for this be stable? this is an amazing feature

[the8472]

Hashbrown PR to remove the drain-on-drop behavior: rust-lang/hashbrown#374

[JakobDegen]

I'd like to suggest an alternative API that is significantly more powerful than this one: entries(&mut self) -> impl Iterator<Item = OccupiedEntryRef>. The API can quite obviously be used to replace drain_filter:

for entry in map.entries() {
    if entry.get().satisfies_condition() {
        entry.remove();
    }
}

However, it is much more powerful and ergonomic for any non-trivial use cases. As far as I can tell these advantages fall into a few categories:

1. Not forcing the use of a closure. Closures are great, but they're not always the most ergonomic thing in the world. Specifically, using a closure interferes with the ability to use the standard effects (try, async) which is a bit of a loss for more complicated conditions.
2. drain_filter() can be very approximately seen as acting like .entries().filter() - essentially this means that it's going to have a tough time supporting any use of .entries() that doesn't look quite like that.
3. VacantEntryRefs are useful. With the .drain_filter() as implemented above, I could still get out a VacantEntryRef, which I could stash somewhere and then use again later if I change my mind about wanting to remove that element.

The obvious problem with this API is that OccupiedEntryRef is not a type that exists in std. That type would have to be added before (or together with) this API. It is my understanding that std is interested in an alternative API to fix the weaknesses of the Entry API we have now anyway, so possibly this could be wrapped up in there?

A second, less obvious problem with this API is that it significantly restricts the space of possible implementations for the std HashMap. Allowing multiple entries into the map to coexist is a non-trivial requirement.

[blagowtf]

any update here? this API is essential for my use case where having ownership of the removed elements would save me from unnecessary clones / allocations...

[the8472]

Currently waiting for a hashbrown release so that drain_filter can be replaced with extract_if.

[blagowtf]

@the8472 Nice. How often are these releases (and do they automatically land in std?) Is the vision ultimately to stabilize the extract_if version in std::collections::HashMap.

[Folyd]

The new version of hashbrown will be released soon. 🎉
rust-lang/hashbrown#434

[saiintbrisson]

Is this ready for the FCP? hashbrown released Jun 5.

[the8472]

On the companion Vec issue some people are asking for a mapped version (passing an owned value) instead so if we implemented that it might make sense to do that for hashmap too.

But that could be discussed as part of the FCP.

[esemeniuc]

Would love to use this feature in stable!

[joshtriplett]

Let's see if we have consensus to stabilize these:

@rfcbot merge

[rfcbot]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

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.