Change:
/// assert_eq!(map.get_key_value(&1), Some((&1, &"a"))); /// assert_eq!(map.get_key_value(&2), None); /// ``` <del> #[unstable(feature = "map_get_key_value", issue = "49347")] </del> <ins> #[stable(feature = "map_get_key_value", since = "1.40.0")] </ins> pub fn get_key_value<Q: ?Sized>(&self, k: &Q) -> Option<(&K, &V)> where K: Borrow<Q>, Q: Ord

Discussion:
Implemented in
Can we add a mutable equivalent? Like , or has that already been discussed?
it was discussed a little here: It was just less clear cut what the API should look like.
Any update on this? I'd like to use this on stable.
Is anything keeping this from stabilization?
Following up with what said, my summarized understanding is this: the 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 would be preferred over reusing the API (i.e., returning . I don't see how the above influences this particular issue, so AFAICT there's nothing keeping this from stabilization at this point. I don't know who else we could ping to get this pushed I'd like to see this on stable too. :P
I believe this needs someone from the 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. 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.
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. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] 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 for info about what commands tagged team members can give me.
I do sometimes look through 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 ), write up a summary comment, and propose a way forward.
Oh and then there’s where the only thing left to do might be a stabilization PR (which anyone can submit). There are some false positives there, though.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.