Tracking issue for {HashMap, BTreeMap}::get_key_value stabilization

[Diggsey]

Implemented in #49346

[bluss]

Can we add a mutable equivalent? Like fn get_key_value_mut<Q>(&mut self, &Q) -> Option<(&K, &mut V)>, or has that already been discussed?

[Diggsey]

@bluss it was discussed a little here: #46992 (comment)

It was just less clear cut what the API should look like.

[joshlf]

Any update on this? I'd like to use this on stable.

[CAD97]

Is anything keeping this from stabilization?

[ErichDonGubler]

Following up with what @Diggsey said, my summarized understanding is this: the get_key_value API for immutable access (which seems to be the entirety of what's being tracked here) seems to have borne no objections, but it was less clear if simply exposing a similar API that merely returns a tuple of mutable references and calling it get_key_value_mut would be preferred over reusing the OccupiedEntry API (i.e., returning Option<OccupiedEntry<_, _>>.

I don't see how the above influences this particular issue, so AFAICT there's nothing keeping this from stabilization at this point. @Diggsey, I don't know who else we could ping to get this pushed through...and I'd like to see this on stable too. :P

[Diggsey]

I believe this needs someone from the @rust-lang/libs team to propose an "fcp merge", or is there something else I need to do here?

On a meta-note, this does seem to be a bit of a gap in the process, with almost 500 open tracking issues, some of which have been sitting around since 2013 and no indication of who is responsible for next steps... Compare to eg. #60602 where the author is on the libs team and able to take a feature from implementation to stabilisation in a single release cycle.

If the stabilisation of this feature is simply not a priority, it would be nice to make that decision publicly.

[sfackler]

The general process is that people who care about a feature ask for it to be stabilized. If no one cares enough to ask about it, it's probably not going to be stabilized.

@rfcbot fcp merge

[rfcbot]

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

• @Amanieu
• @Kimundi
• @SimonSapin
• @alexcrichton
• @dtolnay
• @sfackler
• @withoutboats

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.

[SimonSapin]

@Diggsey I do sometimes look through https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AC-tracking-issue+label%3AT-libs and try to find tracking issues where there is nothing else left to do other than start FCP. If you do find some like that, feel free to ping someone in the team so they can do it. However in a lot of cases there are ongoing design discussions without a clear resolution. In some cases a tracking issue has many comments, and its not obvious whether or not all the issues that have been brought up are in fact resolved even though discussion has stalled. For those, it can be helpful to have someone read through the history of that feature (including potential other threads, like in an RFC or on internals.rlo), write up a summary comment, and propose a way forward.

[SimonSapin]

Oh and then there’s https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AC-tracking-issue+label%3Afinished-final-comment-period+label%3Adisposition-merge where the only thing left to do might be a stabilization PR (which anyone can submit). There are some false positives there, though.