-
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 retain() method for HashMap (retain_hash_collection
)
#36648
Comments
I wonder if that needs an RFC ? Pretty small change to std, but still a change to std |
Small backward-compatible additions do not need an RFC unless they hit some sort of controversy. |
std: Add retain method for HashMap and HashSet Fix rust-lang#36648 r? @bluss
std: Add retain method for HashMap and HashSet Fix rust-lang#36648 r? @bluss
std: Add retain method for HashMap and HashSet Fix rust-lang#36648 r? @bluss
std: Add retain method for HashMap and HashSet Fix rust-lang#36648 r? @bluss
This was added in nightly as an unstable feature |
It would be nice if BTreeMap got retain() as well |
What is holding stabilization now? |
Nothing as far as I know! @rfcbot fcp merge |
Thanks for lightning quick answer @sfackler ! |
Team member @sfackler has proposed to merge this. The next step is review by the rest of the tagged teams: 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. |
retain_hash_collection
)
@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>
.
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
This feature |
@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! |
The final comment period is now complete. |
Closes rust-lang#38863 Closes rust-lang#38980 Closes rust-lang#38903 Closes rust-lang#36648
Stabilize library features for 1.18.0 Closes #38863 Closes #38980 Closes #38903 Closes #36648 r? @alexcrichton @rust-lang/libs
Closes rust-lang#38863 Closes rust-lang#38980 Closes rust-lang#38903 Closes rust-lang#36648
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. |
Yeah, I think the other containers just need implementations and another tracking issue opened, as per #36648 (comment). Go right ahead! |
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.
The HashMap type does not have a retain method like the one in Vec.
The text was updated successfully, but these errors were encountered: