Map::retain

[Gankra]

Like Vec::retain but for Maps.

• HashSet::retain, HashMap::retain (Tracking issue for retain() method for HashMap (retain_hash_collection) rust#36648)
• BTreeSet::retain, BTreeMap::retain (Tracking Issue for {BTreeMap,BTreeSet}::retain rust#79025)

[aji]

👍 this would be excellent

[mbrubeck]

This was implemented for HashMap (but not BTreeMap) in rust-lang/rust#39560.

[Centril]

Triage, @SimonSapin can/should we perhaps do this for BTreeMap as well if possible?

[jeffparsons]

The use case I have for this would be to selectively remove elements within a given range — and I'm guessing that's pretty common. Making the interface work for that would be a bit harder than what was implemented for HashMap.

[Centril]

@jeffparsons These days we would welcome a PR against https://github.com/rust-lang/rust/ to unstably implement this in the standard library. An RFC would likely be overkill. If you decide to write up such a PR, please cc this issue. :)

[jeffparsons]

After familiarizing myself with the BTreeMap source, I think the more valuable thing to implement first would be a cursor API for BTreeMap (and BTreeSet), upon which this and other convenience functions could be easily implemented. I made a very token start on this (it's serious cargo cult stuff at this point) but quickly became frustrated by variants of rust-lang/rust#58633 and put it aside for later.

So... at this point, the things on my mind that more experienced Rust hackers might be able to help answer are:

• What's the most practical way of working on collection types like BTreeMap? Is there a de facto standard workflow that avoids dealing with the whole compiler build system — even if it is, e.g., copying the whole module out of liballoc into a standalone crate for development? (At the moment if I find a spare half hour in an evening to look at this then I spend most of that time struggling with the build system, which is pretty discouraging.)

• Is there enough appetite for a general cursor API that it would make sense to build that as a public API now and have that and the convenience functions (retain, range_retain), behind separate feature flags? Or would it be better to wait for the dust to settle around LinkedList cursors (Tracking issue for LinkedList cursors rust#58533) before mooting an equivalent API for BTreeMap, and treat it as an internal implementation detail for now?

[Centril]

@jeffparsons I typically spam ./x.py -i check until things type check and then I ./x.py test --stage 1 src/libstd for standard library changes. See https://rust-lang.github.io/rustc-guide/how-to-build-and-run.html#running-xpy-and-building-a-stage1-compiler for more info.

[mbrubeck]

There was some incomplete work on BTreeMap/BTreeSet::retain at rust-lang/rust#66747.

[mbrubeck]

BTreeMap::retain has been stabilized for Rust 1.53.0 (scheduled for release in June 2021).