Receiver hash modified when using non-bang #deep_merge

[owst]

Given that the Hash#merge method does not modify the receiver hash, I think it's really confusing that Hash#deep_merge does.

For#merge:

irb --simple-prompt merge.rb
>> h = {}
=> {}
>> h.merge(m: 1)
=> {:m=>1}
>> h
=> {}
>> h.merge!(m!: 2)
=> {:m!=>2}
>> h
=> {:m!=>2}

but for #deep_merge:

irb --simple-prompt deep_merge.rb
>> require 'deep_merge'
=> true
>> h = {}
=> {}
>> h.deep_merge(dm: 1)
=> {:dm=>1}
>> h
=> {:dm=>1}
>> h.deep_merge!(dm!: 2)
=> {:dm=>1, :dm!=>2}
>> h
=> {:dm=>1, :dm!=>2}

I see that #deep_merge! does have different behaviour for unmergeables, but I wonder if instead of using a ! suffix, is should instead use a prefix, in a similar manner to ko_deep_merge!, for consistency within this library.

Overall though, I think consistency with the stdlib is important, and therefore #deep_merge should not modify the receiver hash. As a test, I think this should not raise (as it currently does) {}.freeze.deep_merge(a: 1).

[santib]

I agree with @owst. I opened a PR, in case the maintainers are fine with the change we also need to change the README and probably other docs too.

[Fryguy]

I agree with this one as well, but it will require a major version bump due to a change in signature. We'd also have to come up with new methods for the existing split between preserve_unmergeables => true and false (or perhaps just change the default to false).

[gregorbg]

I just stumbled into this problem and it prompted us to add an extra deep_dup in our codebase. It works but is hacky, any chance of getting a proper fix?