Printing hashmaps


use std::collections::HashMap;

let mut scores = HashMap::new();

scores.insert(String::from("Blue"), 10);
scores.insert(String::from("Yellow"), 50);

for (key, value) in &scores {
    println!("{}: {}", key, value);


Yellow: 50
Blue: 10

How come the yellow: 50 gets printed out first? Shouldn’t it be Blue: 10 that gets printed out first cause we added this first?

And also in this line of code

for (key, value) in &scores {
    println!("{}: {}", key, value);

How come we are using &scores instead of scores?

HashMap does not keep keys in order of insertion.
From docs:

pub fn iter(&self) -> Iter<K, V>
An iterator visiting all key-value pairs in arbitrary order.

You will have to track it by yourself or use some crate, which implements it for you, for example linked-hash-map .

1 Like

Another option is indexmap, which maintains insertion order and lets you retrieve items by usize index, in addition to normal hashed key lookups.


You could use either. The difference is that if you use scores, you will consume the HashMap and you will not be able to use it later. When using &scores, you can use the HashMap later, but the types of key and value will be references.

1 Like

Some additional context as to why it works this way - for loops are built on top of the IntoIterator trait. Whatever you pass after the in keyword will implicitly have IntoIterator::into_iter called on it. So let’s find the relevant implementations for your case!

  • The type of scores is HashMap, so impl IntoIterator for HashMap is used - this returns an iterator of values, so it must consume the HashMap.
  • The type of &scores is &Hashmap, so impl IntoIterator for &HashMap is used - this returns an iterator of references, so it doesn’t consume the original HashMap.

There’s more good info on this behavior in the std::iter docs.