Tracking issue for `#![feature(entry_insert)]`

[passcod]

This is a tracking issue for the Entry::insert_entry method on HashMap and BTreeMap introduced in #60142 (comment).

• Implementation for HashMap: Implement (HashMap) Entry::insert as per #60142 #64656
  • Stabilised in 1.59: Stabilise entry_insert #90345 Re-stabilised in 1.83: Stabilize entry_insert #130290
    • De-stabilized in Destabilise entry_insert #94105

   impl<'a, K, V> Entry<'a, K, V> {
      pub fn insert_entry(self, value: V) -> OccupiedEntry<'a, K, V> {…}
  }

• Implementation for BTreeMap: btree: add {Entry,VacantEntry}::insert_entry #133042
  • Stabilization

[TethysSvensson]

This does not appear to be compatible with #44286, as the following code will panic.

#![feature(map_entry_replace, entry_insert)]
use std::collections::HashMap;

fn main() {
    HashMap::new().entry(0).insert(0).replace_key();
}

It seems to me that the two APIs are fundamentally incompatible, or at least they are currently incompatible without panicking.

The API in #44286 assumes that an OccupiedEntry will always refer to two keys, the existing one and the one used for the lookup, while this feature will break that assumption. In fact, the key field in OccupiedEntry and RustcOccupiedEntry in hashbrown could be a K instead of an Option<K> if this API was not supported.

[TethysSvensson]

It seems to me that it is a bit silly to use an Option to track at run-time what we should already know at compile time. Wouldn't it make more sense to have a different type from OccupiedEntry, which did not contain a key?

I could imagine this would also be useful as a stepping stone towards implementing something like rust-lang/rfcs#1769.

[passcod]

 if this API was not supported.

I'm a bit rusty with this PR, but am I correct in saying that the entry_insert API is impossible to replicate from user code, while the map_entry_replace one is, as per the original PR? (Albeit not with the same efficiency) Of course I'd much rather a solution that supports both uses is found

[TethysSvensson]

@passcod I believe you mostly are correct on both parts of your statement.

I do not think the Entry::insert function can be implemented in safe rust, as it allows the creation of an OccupiedEntry without an associated key. I cannot see how it would be possible to do that in safe rust.

The OccupiedEntry::replace_entry and OccupiedEntry::replace_key functionality can be implemented in safe rust, using a combination of OccupiedEntry::remove and HashMap::insert.

However I do not think it is possible to implement it as a function in safe rust. You would need to pass both the HashMap and the Entry as an argument in the same function, however the lifetime on the Entry prevents use of the HashMap until the Entry has been dropped.

[Nokel81]

Why isn't the signature of this method pub fn insert(self, value: V) -> &'a mut V like the or_*** methods?

[passcod]

The motivation is to be able to reference the key (or the entry, more generally) even after inserting a value.

[lamafab]

The current implementation is kind of limited, you cannot do something like this:

fn insert(&mut self, msg: Message) -> &Message {
  self.map.entry(msg).insert(0).key()

error[E0515]: cannot return value referencing temporary value

It would be convenient if you could implement this in a way which says "insert the key and return a reference of the key from within the HashMap".

Currently, you'd have to do this ugly work-around:

fn insert(&mut self, msg: Message) -> &Message {
  let msg2 = msg.clone();
  self.map.entry(msg).insert(0); // or just `.or_insert()`
  self.map.get_key_value(&msg2).unwrap().0

[shepmaster]

@lamafab I think you want a function like

impl<'a, K, V> OccupiedEntry<'a, K, V> {
    pub fn into_key(self) -> &'a K { /* ... */ }
}