allow providing the key at insertion time for EntryRef

[djugei]

Either explicitly through insert_kv or implicitly through insert_clone.

I have added an assert in insert_kv just to be sure, but if it is only a logic error to insert a different key at an entry or is caught deeper in the stack it should be removed/changed to debug_assert.

If this is something the maintainers are interested in i can implement the EntryRef and OccupiedEntryRef variants and document them.

[cuviper]

I have added an assert in insert_kv just to be sure, but if it is only a logic error to insert a different key at an entry or is caught deeper in the stack it should be removed/changed to debug_assert.

I expect we do want a full assert, just like we did in HashSet::get_or_insert_with:

hashbrown/src/set.rs

Line 957 in eea9804

assert!(value.equivalent(&new), "new value is not equivalent");

[djugei]

i think i will drop the insert_clone as insert_kv already covers the usecase.
if passing the wrong item is just a logic error i do think that using debug_assert is the correct move, though it is somewhat likely for the compiler to be smart even about the full assert.

should i make the full pr?

[cuviper]

I'll defer to @Amanieu to decide on the API design.

[djugei]

i disagree with clippy on this one.

[djugei]

@Amanieu can i get some feedback on the api design here? i would like to start depending on the main hashbrown again.

this saves clones when trying to insert in a loop.

[Amanieu]

Overall, I think the API additions make sense. I've added some comments on the specific.

And finally, the docs will need to be improved.

[djugei]

EntryRef already has or_insert_with_key which is a bit of a name collision, so i am for now only adding the functionality to VacantEntryRef.

[djugei]

@Amanieu i have integrated the suggestions. Unsure if the docs are enough, i mainly point to the regular insert docs instead of duplicating.

This should be ready to merge now i think, i have rebased it on top of master.