Tracking issue for retain() method for HashMap (retain_hash_collection)

[navaati]

The HashMap type does not have a retain method like the one in Vec.

[Cobrand]

I wonder if that needs an RFC ? Pretty small change to std, but still a change to std

[nagisa]

Small backward-compatible additions do not need an RFC unless they hit some sort of controversy.

[mbrubeck]

This was added in nightly as an unstable feature retain_hash_collection with a link to this issue. The issue should be re-opened for tracking stabilization. CC @rust-lang/libs

[jrmuizel]

It would be nice if BTreeMap got retain() as well

[alexbool]

What is holding stabilization now?

[sfackler]

Nothing as far as I know!

@rfcbot fcp merge

[alexbool]

Thanks for lightning quick answer @sfackler !

[rfcbot]

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

• @BurntSushi
• @Kimundi
• @alexcrichton
• @aturon
• @brson
• @sfackler

No concerns currently listed.

Once these reviewers reach consensus, 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.

[alexcrichton]

@rfcbot reviewed

…

On Apr 15, 2017 12:56 AM, "Rust RFC bot" ***@***.***> wrote: Team member @sfackler <https://github.com/sfackler> has proposed to merge this. The next step is review by the rest of the tagged teams: - @BurntSushi <https://github.com/BurntSushi> - @Kimundi <https://github.com/Kimundi> - @alexcrichton <https://github.com/alexcrichton> - @aturon <https://github.com/aturon> - @brson <https://github.com/brson> - @sfackler <https://github.com/sfackler> No concerns currently listed. Once these reviewers reach consensus, 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 <https://github.com/dikaiosune/rust-dashboard/blob/master/RFCBOT.md> for info about what commands tagged team members can give me. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#36648 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD95KxrO4JKWabezfOvXwUf8kgkPlf2ks5rv6VRgaJpZM4KD3VI> .

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[Mark-Simulacrum]

BTreeMap, as mentioned above doesn't appear to have this method. Should that be added before stabilization? Would that require a separate feature at this point?

[F001]

This feature retain_hash_collection is only for HashMap and HashSet. We should assign another name for the feature for BTreeMap and BTreeSet, such as retain_btree_collection.

[alexcrichton]

@Mark-Simulacrum yeah at this point we'd probably have a separate issue for that, but we'd definitely welcome a PR to implement it!

[rfcbot]

The final comment period is now complete.

[ahicks92]

If doing these isn't going to need an RFC, can someone (me? I feel like I'm volunteering) put them on all the containers?

Doing an RFC for this was something I was planning to do when I had this hypothetical thing called time, but if it's not needed then someone should just go for it. Retain is the only way to express loops that might delete, and I don't see why we shouldn't have it on everything where it makes sense.

[Mark-Simulacrum]

Yeah, I think the other containers just need implementations and another tracking issue opened, as per #36648 (comment). Go right ahead!