How to iterate through a Hashmap, print the key/value and remove the value in Rust?

后端 未结 2 896
我在风中等你
我在风中等你 2021-01-07 17:08

This should be a trivial task in any language. This isn\'t working in Rust.

use std::collections::HashMap;

fn do_it(map: &mut HashMap

        
相关标签:
2条回答
  • 2021-01-07 17:39

    There are at least two reasons why this is disallowed:

    1. You would need to have two concurrent mutable references to map — one held by the iterator used in the for loop and one in the variable map to call map.remove.

    2. You have references to the key and the value within the map when trying to mutate the map. If you were allowed to modify the map in any way, these references could be invalidated, opening the door for memory unsafety.

    A core Rust principle is Aliasing XOR Mutability. You can have multiple immutable references to a value or you can have a single mutable reference to it.

    I didn't think moving/borrowing applied to references.

    Every type is subject to Rust's rules of moving as well as mutable aliasing. Please let us know what part of the documentation says it isn't so we can address that.

    Why it is trying to move a reference?

    This is combined of two parts:

    1. You can only have a single mutable reference
    2. for loops take the value to iterate over by value

    When you call for (k, v) in map {}, the ownership of map is transferred to the for loop and is now gone.


    I'd perform an immutable borrow of the map (&*map) and iterate over that. At the end, I'd clear the whole thing:

    fn do_it(map: &mut HashMap<String, String>) {
        for (key, value) in &*map {
            println!("{} / {}", key, value);
        }
        map.clear();
    }
    

    remove every value with a key that starts with the letter "A"

    I'd use HashMap::retain:

    fn do_it(map: &mut HashMap<String, String>) {
        map.retain(|key, value| {
            println!("{} / {}", key, value);
    
            !key.starts_with("a")
        })
    }
    

    This guarantees that key and value no longer exist when the map is actually modified, thus any borrow that they would have had is now gone.

    0 讨论(0)
  • 2021-01-07 17:45

    This should be a trivial task in any language.

    Rust is preventing you from mutating the map while you are iterating over it. In most languages this is allowed, but often the behaviour is not well-defined, and removal of the item can interfere with the iteration, compromising its correctness.

    Why it is trying to move a reference?

    HashMap implements IntoIterator, so your loop is equivalent to:

    for (key, value) in map.into_iter() {
        println!("{} / {}", key, value);
        map.remove(key);
    }
    

    If you look at the definition of into_iter, you'll see that it takes self, not &self or &mut self. Your variable map is a reference, so it is implicitly dereferenced to get at self, which is why the error says that *map has been moved.

    The API is intentionally built that way so that you can't do anything dangerous while looping over a structure. Once the loop is complete, the ownership of the structure is relinquished and you can use it again.

    One solution is to keep track of the items you intend to remove in a Vec and then remove them afterwards:

    fn do_it(map: &mut HashMap<String, String>) {
        let mut to_remove = Vec::new();
        for (key, value) in &*map {
            if key.starts_with("A") {
                to_remove.push(key.to_owned());
            }
        }
        for key in to_remove.iter() {
            map.remove(key);
        }
    }
    

    You may also use an iterator to filter the map into a new one. Perhaps something like this:

    fn do_it(map: &mut HashMap<String, String>) {
        *map = map.into_iter().filter_map(|(key, value)| {
            if key.starts_with("A") {
                None
            } else {
                Some((key.to_owned(), value.to_owned()))
            }
        }).collect();
    }
    

    But I just saw Shepmaster's edit - I had forgotten about retain, which is better. It's more concise and doesn't do unnecessary copying as I have done.

    0 讨论(0)
提交回复
热议问题