Strange, unexpected behavior (disappearing/changing values) when using Hash default value, e.g. Hash.new([])

by

First, note that this behavior applies to any default value that is subsequently mutated (e.g. hashes and strings), not just arrays. It also applies similarly to the populated elements in Array.new(3) { [] }.

TL;DR: Use Hash.new { |h, k| h[k] = [] } if you want the most idiomatic solution and don’t care why.

What doesn’t work

Why Hash.new([]) doesn’t work

Let’s look more in-depth at why Hash.new([]) doesn’t work:

h = Hash.new([])
h[0] << 'a'  #=> ["a"]
h[1] << 'b'  #=> ["a", "b"]
h[1]         #=> ["a", "b"]

h[0].object_id == h[1].object_id  #=> true
h  #=> {}

We can see that our default object is being reused and mutated (this is because it is passed as the one and only default value, the hash has no way of getting a fresh, new default value), but why are there no keys or values in the array, despite h[1] still giving us a value? Here’s a hint:

h[42]  #=> ["a", "b"]

The array returned by each [] call is just the default value, which we’ve been mutating all this time so now contains our new values. Since << doesn’t assign to the hash (there can never be assignment in Ruby without an = present†), we’ve never put anything into our actual hash. Instead we have to use <<= (which is to << as += is to +):

h[2] <<= 'c'  #=> ["a", "b", "c"]
h             #=> {2=>["a", "b", "c"]}

This is the same as:

h[2] = (h[2] << 'c')

Why Hash.new { [] } doesn’t work

Using Hash.new { [] } solves the problem of reusing and mutating the original default value (as the block given is called each time, returning a new array), but not the assignment problem:

h = Hash.new { [] }
h[0] << 'a'   #=> ["a"]
h[1] <<= 'b'  #=> ["b"]
h             #=> {1=>["b"]}

What does work

The assignment way

If we remember to always use <<=, then Hash.new { [] } is a viable solution, but it’s a bit odd and non-idiomatic (I’ve never seen <<= used in the wild). It’s also prone to subtle bugs if << is inadvertently used.

The mutable way

The documentation for Hash.new states (emphasis my own):

If a block is specified, it will be called with the hash object and the key, and should return the default value. It is the block’s responsibility to store the value in the hash if required.

So we must store the default value in the hash from within the block if we wish to use << instead of <<=:

h = Hash.new { |h, k| h[k] = [] }
h[0] << 'a'  #=> ["a"]
h[1] << 'b'  #=> ["b"]
h            #=> {0=>["a"], 1=>["b"]}

This effectively moves the assignment from our individual calls (which would use <<=) to the block passed to Hash.new, removing the burden of unexpected behavior when using <<.

Note that there is one functional difference between this method and the others: this way assigns the default value upon reading (as the assignment always happens inside the block). For example:

h1 = Hash.new { |h, k| h[k] = [] }
h1[:x]
h1  #=> {:x=>[]}

h2 = Hash.new { [] }
h2[:x]
h2  #=> {}

The immutable way

You may be wondering why Hash.new([]) doesn’t work while Hash.new(0) works just fine. The key is that Numerics in Ruby are immutable, so we naturally never end up mutating them in-place. If we treated our default value as immutable, we could use Hash.new([]) just fine too:

h = Hash.new([].freeze)
h[0] += ['a']  #=> ["a"]
h[1] += ['b']  #=> ["b"]
h[2]           #=> []
h              #=> {0=>["a"], 1=>["b"]}

However, note that ([].freeze + [].freeze).frozen? == false. So, if you want to ensure that the immutability is preserved throughout, then you must take care to re-freeze the new object.

Conclusion

Of all the ways, I personally prefer “the immutable way”—immutability generally makes reasoning about things much simpler. It is, after all, the only method that has no possibility of hidden or subtle unexpected behavior. However, the most common and idiomatic way is “the mutable way”.

As a final aside, this behavior of Hash default values is noted in Ruby Koans.

† This isn’t strictly true, methods like instance_variable_set bypass this, but they must exist for metaprogramming since the l-value in = cannot be dynamic.

More Related Contents:

  1. How to remove empty string in hash
  2. Is there any difference between the `:key => “value”` and `key: “value”` hash notations?
  3. Converting a nested hash into a flat hash
  4. Is Hash Rocket deprecated?
  5. Ruby Style: How to check whether a nested hash element exists
  6. Group hashes by keys and sum the values
  7. How do I search within an array of hashes by hash values in ruby?
  8. Ruby Hash with duplicate keys?
  9. Performance of Arrays and Hashes in Ruby
  10. Comparing ruby hashes [duplicate]
  11. Find key/value pairs deep inside a hash containing an arbitrary number of nested hashes and arrays
  12. Ruby method Array#
  13. How to get a specific output iterating a hash in Ruby?
  14. Accessing elements of nested hashes in ruby [duplicate]
  15. How do I create a SHA1 hash in ruby?
  16. Convert array of 2-element arrays into a hash, where duplicate keys append additional values
  17. How to assign hash[‘a’][‘b’]= ‘c’ if hash[‘a’] doesn’t exist?
  18. Is order of a Ruby hash literal guaranteed?
  19. How do methods use hash arguments in Ruby?
  20. ruby using the “&:methodname” shortcut from array.map(&:methodname) for hash key strings rather than methodname
  21. How do I compare two hashes?
  22. What is the Ruby (spaceship) operator?
  23. Why is division in Ruby returning an integer instead of decimal value?
  24. Difference between \A \z and ^ $ in Ruby regular expressions
  25. How to implement Enums in Ruby?
  26. Issue updating Ruby on Mac with Xcode 4.3.1
  27. How to count duplicates in Ruby Arrays
  28. Interpolating a string into a regex
  29. Understanding Ruby and OS I/O buffering
  30. Rake “already initialized constant WFKV_” warning

Leave a Comment