From: merch-redmine@... Date: 2020-03-17T17:11:11+00:00 Subject: [ruby-core:97535] [Ruby master Feature#16175] Object#clone(freeze: true) is inconsistent with Object#clone(freeze: false) Issue #16175 has been updated by jeremyevans0 (Jeremy Evans). Pull request 2954 was merged early today, so I was able to work on this. I submitted https://github.com/ruby/ruby/pull/2969 to implement it. In the recent dev meeting notes, @akr stated `freeze: nil` should be supported, but @matz said he didn't see a need to introduce it. After the merging of pull request 2954, Object#clone is partially written in Ruby via `kernel.rb`, and it would require more complex code not to support it. Additionally, `delegate` and `set` would both require more complex code if it was not supported. Therefore, I implemented support for `freeze: nil`, and made `nil` the default value of the `freeze` keyword argument for `initialize_clone`. ---------------------------------------- Feature #16175: Object#clone(freeze: true) is inconsistent with Object#clone(freeze: false) https://bugs.ruby-lang.org/issues/16175#change-84696 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- In #12300, the new keyword `freeze:` was introduced, allowing this: ```ruby h = {}.freeze h.clone.frozen? # => true h.clone(freeze: false).frozen? # => false ``` Though, it turns to me that behavior is not symmetric: ```ruby h = {} h.frozen? # => false h.clone.frozen? # => false h.clone(freeze: true).frozen? # => false -- I expected true here! ``` I wonder, if it is "by design" and should be addressed in docs, or just an implementation inconsistency that can be fixed? ---Files-------------------------------- freeze-true.patch (1.47 KB) clone-freeze-true-16175.patch (4.42 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: