Allow replacing HashMap entries #44278

Binero · 2017-09-02T21:57:23Z

This is an obvious API hole. At the moment the only way to retrieve an entry from a HashMap is to get an entry to it, remove it, and then insert a new entry. This PR allows entries to be replaced.

rust-highfive · 2017-09-02T21:57:36Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @BurntSushi (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

…aced.

kennytm · 2017-09-03T09:38:57Z

src/libstd/collections/hash/map.rs

+    ///
+    /// ```
+    #[stable(feature = "rust1", since = "1.20.0")]
+    pub fn replace(mut self, value: V) -> (K, V) {


This new API should be #[unstable].

kennytm · 2017-09-03T09:40:03Z

Why not apply this to BTreeMap too?

Binero · 2017-09-03T13:36:34Z

@kennytm It is non-trivial to implement it for BTreeMap. BTreeMap's entry does not have ownership of the key. Giving it ownership would break BTreeMap::replace.

Not sure how to implement recovery of a BTreeMap's entry without breaking the existing APIs. Both of these map APIs are littered with methods that take by ownership, use a borrow and then throw away the value they took ownership of.

Binero · 2017-09-03T14:06:18Z

I am quite inexperienced with the std, and I am unsure how such an unstable attribute would look.

Adding #[unstable(feature = "rust1", issue = "44286")] gives a compile error during tests:

error: use of unstable library feature 'rust1' (see issue #44286)

kennytm · 2017-09-03T14:25:48Z

@Binero You would first need to pick a name of the feature, say entry_replace. When nightly user tries to use your API, they will need to add #![feature(entry_replace)].

The syntax of #[unstable] attribute is:

#[unstable(feature = "entry_replace", reason = "recently added", issue = "44286")]

The doctest examples will need to be modified to include #![feature(entry_replace)]:

    /// # Examples
    ///
    /// ```
    /// #![feature(entry_replace)]
    /// # fn main() {
    /// use std::collections::HashMap;
    /// use std::collections::hash_map::Entry; 
    /// // ...
    /// # }
    /// ```

Binero · 2017-09-07T16:40:20Z

Not sure why this is waiting on author?

carols10cents · 2017-09-11T15:10:42Z

@Binero I'm not sure either. Maybe because of the test failure? It looks like an osx worker had a network failure though; I've restarted that job.

I think this is ready for review again @BurntSushi !

BurntSushi

I left a few nits, and mechanically, this looks fine to me.

Is this something we definitely want though? Do you have a use case in mind where this method is useful?

BurntSushi · 2017-09-11T21:25:48Z

src/libstd/collections/hash/map.rs

+    /// # Examples
+    ///
+    /// ```
+    /// # #![feature(map_entry_replace)]


I think we include the feature toggle in the docs so that end users know that it is necessary. So I'd remove the # prefix here.

BurntSushi · 2017-09-11T21:25:59Z

src/libstd/collections/hash/map.rs

+    /// }
+    ///
+    /// assert_eq!(map.get("poneyland"), Some(&16));
+    ///


Remove blank line?

BurntSushi · 2017-09-11T21:29:58Z

src/libstd/collections/hash/map.rs

+    /// use std::collections::hash_map::Entry;
+    ///
+    /// let mut map: HashMap<String, u32> = HashMap::new();
+    /// map.insert(String::from("poneyland"), 15);


I think we use "poneyland".to_string()?

BurntSushi · 2017-09-11T21:30:07Z

src/libstd/collections/hash/map.rs

+    /// let mut map: HashMap<String, u32> = HashMap::new();
+    /// map.insert(String::from("poneyland"), 15);
+    ///
+    /// if let Entry::Occupied(entry) = map.entry(String::from("poneyland")) {


Same as above, use to_string.

Binero · 2017-09-12T13:38:44Z

@BurntSushi The Entry-API serves as a temporary result, to prevent having to lookup entries in the HashMap multiple times.

Right now, to get a key out of a HashMap, you have to do the following:

Create an entry to the key-value pair you want to remove. (lookup)
Remove it. (shifts elements following the removed entry to the left)
Insert a new entry. (lookup + shifts those same elements back to the right)

With this addition, the process is simplified to the following:

Create an entry to the key-value pair you want to remove. (lookup)
Replace it. (O(1))

arthurprs · 2017-09-20T17:17:52Z

src/libstd/collections/hash/map.rs

+    pub fn replace(mut self, value: V) -> (K, V) {
+        let (old_key, old_value) = self.elem.read_mut();
+
+        let old_key = mem::replace(old_key, self.key.unwrap());


One can take the key out of the entry using take_key before replace, so this key.unwrap() can fail. It needs a custom message at least.

arthurprs · 2017-09-20T17:24:56Z

I think this (sort of) already possible using occupied.take_key() and replace(occupied.get_mut(), new_value).

The difference is that take_key will return the key passed to entry() instead of the one inside the hashmap.

Binero · 2017-09-23T12:04:10Z

@arthurprs take_key is only called internally, and the entry is always consumed after usage. Furthermore, take_key returns the key the entry was created with, which doesn't address the issue at all. If one wanted to have the new key, one wouldn't create an Entry. The point of the replace function is to recover the old key.

arthurprs · 2017-09-23T15:48:40Z

Indeed, thanks for clarifying.

arthurprs

Looks good.

BurntSushi · 2017-09-25T21:20:44Z

@Binero That's good enough for me! Thanks for clarifying. Should this get an entry in the unstable book before merging?

alexcrichton · 2017-09-28T14:23:09Z

@BurntSushi oh we typically don't have an entry per unstable library API as the docs here typically suffice for that, in which case I'll..

@bors: r=BurntSushi

Thanks for the PR @Binero!

bors · 2017-09-28T14:23:10Z

📌 Commit d3de465 has been approved by BurntSushi

bors · 2017-09-28T18:52:55Z

⌛ Testing commit d3de465 with merge 3c96d40...

Allow replacing HashMap entries This is an obvious API hole. At the moment the only way to retrieve an entry from a `HashMap` is to get an entry to it, remove it, and then insert a new entry. This PR allows entries to be replaced.

bors · 2017-09-28T22:52:54Z

☀️ Test successful - status-appveyor, status-travis
Approved by: BurntSushi
Pushing 3c96d40 to master...

rust-highfive assigned BurntSushi Sep 2, 2017

Added a way to retrieve the key out of a HashMap when it's being repl…

e9f01bc

…aced.

Binero force-pushed the master branch from 763257b to e9f01bc Compare September 2, 2017 22:20

kennytm reviewed Sep 3, 2017

View reviewed changes

Binero mentioned this pull request Sep 3, 2017

Tracking issue for HashMap OccupiedEntry::{replace_key, replace_entry} #44286

Closed

2 tasks

Binero mentioned this pull request Sep 3, 2017

Extend entry API to work on borrowed keys. rust-lang/rfcs#1769

Closed

Marked Entry::replace as unstable.

a312b47

arielb1 added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Sep 5, 2017

carols10cents added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 11, 2017

BurntSushi reviewed Sep 11, 2017

View reviewed changes

BurntSushi added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 11, 2017

Addressed @BurntSuchi's remarks regarding Entry::replace

d3de465

carols10cents added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 18, 2017

arthurprs suggested changes Sep 20, 2017

View reviewed changes

arthurprs reviewed Sep 23, 2017

View reviewed changes

BurntSushi added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 25, 2017

alexcrichton added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 28, 2017

bors merged commit d3de465 into rust-lang:master Sep 28, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow replacing HashMap entries #44278

Allow replacing HashMap entries #44278

Binero commented Sep 2, 2017

rust-highfive commented Sep 2, 2017

kennytm Sep 3, 2017

kennytm commented Sep 3, 2017

Binero commented Sep 3, 2017 •

edited

Loading

Binero commented Sep 3, 2017

kennytm commented Sep 3, 2017

Binero commented Sep 7, 2017

carols10cents commented Sep 11, 2017

BurntSushi left a comment

BurntSushi Sep 11, 2017

BurntSushi Sep 11, 2017

BurntSushi Sep 11, 2017

BurntSushi Sep 11, 2017

Binero commented Sep 12, 2017

arthurprs Sep 20, 2017

arthurprs commented Sep 20, 2017

Binero commented Sep 23, 2017

arthurprs commented Sep 23, 2017

arthurprs left a comment

BurntSushi commented Sep 25, 2017

alexcrichton commented Sep 28, 2017

bors commented Sep 28, 2017

bors commented Sep 28, 2017

bors commented Sep 28, 2017

Allow replacing HashMap entries #44278

Allow replacing HashMap entries #44278

Conversation

Binero commented Sep 2, 2017

rust-highfive commented Sep 2, 2017

kennytm Sep 3, 2017

Choose a reason for hiding this comment

kennytm commented Sep 3, 2017

Binero commented Sep 3, 2017 • edited Loading

Binero commented Sep 3, 2017

kennytm commented Sep 3, 2017

Binero commented Sep 7, 2017

carols10cents commented Sep 11, 2017

BurntSushi left a comment

Choose a reason for hiding this comment

BurntSushi Sep 11, 2017

Choose a reason for hiding this comment

BurntSushi Sep 11, 2017

Choose a reason for hiding this comment

BurntSushi Sep 11, 2017

Choose a reason for hiding this comment

BurntSushi Sep 11, 2017

Choose a reason for hiding this comment

Binero commented Sep 12, 2017

arthurprs Sep 20, 2017

Choose a reason for hiding this comment

arthurprs commented Sep 20, 2017

Binero commented Sep 23, 2017

arthurprs commented Sep 23, 2017

arthurprs left a comment

Choose a reason for hiding this comment

BurntSushi commented Sep 25, 2017

alexcrichton commented Sep 28, 2017

bors commented Sep 28, 2017

bors commented Sep 28, 2017

bors commented Sep 28, 2017

Binero commented Sep 3, 2017 •

edited

Loading