RFC: get collection keys

[seppo0010]

Rendered

cc @gankro @alexcrichton

[apasel422]

For clarity, it would be great if this RFC could include the signatures for the new methods, even if the names are still being bikeshedded.

CC rust-lang/rust#26531.

[apasel422]

And could this also mention the following potential additions to the OccupiedEntry API (modulo naming):

impl<'a, K, V> OccupiedEntry<'a, K, V> {
    fn key(&self) -> &K;
    fn keyed_remove(self) -> (K, V);
    fn keyed_get_mut(&mut self) -> (&K, &mut V);
    fn keyed_get(&self) -> (&K, &V);
}

The last method isn't strictly necessary, but is provided for consistency with keyed_get_mut. keyed_get_mut is necessary because you cannot borrow self mutably and immutably at the same time. For completion, it might also be worthwhile to have

impl<'a, K, V> OccupiedEntry<'a, K, V> {
    fn keyed_into_mut(self) -> (&'a K, &'a mut V);
}

[Gankra]

These types are slated for deprecation. Regardless, this RFC is proposing a standard map/set API, and as such all maps/sets should implement them unless infeasible.

[apasel422]

It's really too bad that we can't change

fn get<Q>(&self, key: &Q) -> Option<&V>;

to

fn get<Q>(&self, key: &Q) -> Option<(&K, &V)>;

due to backwards compatibility concerns. Instead, we're going to end up with an explosion of method variants when this change would subsume all uses. I guess a future Map trait could solve this (i.e. we could wait to add these until then, and only then on the trait impl itself, not as inherent methods), but then the naming would be inconsistent between the concrete types and the traits.

[seppo0010]

Thanks for the feedback, @gankro. I'll update the PR when I get a chance.

One thing I'm not certain is the Entry API. The Entry receives a new Key and the HashMap may already have a Key that's equal to the new one. In that case, which key should be exposed, the existing one or the one used to create the Entry?

[seppo0010]

I don't think I can make this happen. Someone else should take care of this if desired.

[apasel422]

I may be interested in taking this over.

[apasel422]

I'm working on this at https://github.com/apasel422/rfcs/blob/collection-keys/text/0000-collection-keys.md.

[dhardy]

What's the state of this? Does it still need revision with @gankro 's comments? @apasel422, your link is broken.

Completeness appears to demand a lot of extra functions. I don't know how far it's worth pursuing completeness. For what it's worth, all I want is get_key and remove_key.

[apasel422]

This was partially addressed by RFC 1194.

[vitiral]

I would also like this, although my use case is mostly "as a newbie I'm confused why this doesn't exist." I am trying to use Rc and want to clone the key for correctness, but can't.