Add entry_ref API to HashMap#301
Conversation
Amanieu
left a comment
Amanieu
left a comment
There was a problem hiding this comment.
Great work! I'm really glad to see this feature, it was much needed!
cc @rust-lang/libs-api since this API is likely to come to the standard library HashMap soon and I would like to iterate on the API within the hashbrown repo first.
src/map.rs
Outdated
| } | ||
|
|
||
| impl<'a, K, Q: ?Sized> KeyOrRef<'a, K, Q> { | ||
| pub fn into_owned(self) -> K |
There was a problem hiding this comment.
KeyOrRef is a private type, so this method doesn't need to be pub.
|
I'm not sure why the update triggered the clippy warning for missing safety docs on the |
|
It's most likely because CI always uses the latest rust nightly and this lint was recently added to clippy. I think you can safely just disable this lint. This |
|
Ok, lint is disabled. Regarding the |
|
For |
|
Thanks! Added the impls. |
|
@bors r+ |
|
📌 Commit 7c545e1 has been approved by |
|
☀️ Test successful - checks-actions |
3 participants
An initial attempt at an
entry_refAPI to do the simple case thatraw_entry_mutis used for. I basically attempted to mirror the existingentryAPI, but allow passing a borrowed version of the key. I left off mirroring theSendandSynctraits as I'm not sure what these should be.The relationships I use between the key
Kand borrowed keyQisK: Borrow<Q> + From<&Q>. The reason for not usingQ: ToOwned<K>is to support key types likeRc<str>(which is used in a couple of the doctests), which would not be possible withto_owned().Hopefully this is somewhat useful.