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);
}

[Gankro]

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.

[Gankro]

I'd nix the Hash* instances. Describe the generic API.

[Gankro]

Arguably you can yield &mut K for the hypothetical desire to mutate things in the key that don't affect hash/eq/ord. This of course allows you to mess up hash/eq/ord but the collection can't possibly care since that can already be true thanks to:

• Interior mutability
• Bad implementations of hash/eq/ord

The collection is already locked up yielding the &mut V, so it's not an ownership problem. In fact the &K is also mutably borrowing the map because of how lifetimes work. Obviously mutating a key in place is super sketchy, and I'm not clear that anyone can reasonably suggest they want this. Still... you could.

[apasel422]

I'm not sure I'm in favor of allowing key mutation, but if we were to expose &mut K, how would that affect IterMut types? For backwards compatibility, we would be unable to yield (&mut K, &mut V) without introducing a new mode of iteration, right?

[Gankro]

This is a good point. &mut K was honestly more of a musing; I ultimately probably wouldn't go for it, if only as a lint for "you shouldn't be mutating this".

[Gankro]

We generally voice RFCs as "do this thing" and not "we could do this thing".

[Gankro]

Also this sentence is troubled. Might I suggest "None of these methods provide access to the key" or something.

[Gankro]

Either propose this for certain or add it as an alternative or unresolved question.

[Gankro]

This doesn't solve the Set usecase.

[Gankro]

This is a bit strange...

[Gankro]

This needs to be massively fleshed out. I would argue that there are two major motivators:

• Sets
• Entries

Entries would primarily like to be able to reflect on the key to complete the construction of the value. Potentially also to decide whether to really do the insertion, though I don't expect this much or at all.

Sets on the other hand would like to be able to talk about the key at all. In particular you might use a Set as a cache by indexing on only a small fragment of the key (e.g. an integer id). For technical reasons it may be infeasible or just ineffecient to split the key into a proper (key, value) pair.

The rest of Maps are for the most part, I think, just a nice-to-have. Largely the extended Map API is just needed to implement the new Set API on top of (since Sets are generally trivial Map wrappers).

[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.