From: merch-redmine@... Date: 2019-09-23T23:23:59+00:00 Subject: [ruby-core:95052] [Ruby master Feature#16175] Object#clone(freeze: true) is inconsistent with Object#clone(freeze: false) Issue #16175 has been updated by jeremyevans0 (Jeremy Evans). File clone-freeze-true-16175.patch added Attached is an alternative approach for implementing this. It uses `VALUE` for the `kwfreeze` variable, so we can use `Qundef` instead of the magic value of `-1` for the default behavior. It also updates the documentation to reflect you can use `true` or `false`. Technically, this feature breaks backwards compatibility, because `freeze: true` did not freeze clones of unfrozen receivers previously. However, it seems unlikely that someone would rely on that behavior. ---------------------------------------- Feature #16175: Object#clone(freeze: true) is inconsistent with Object#clone(freeze: false) https://bugs.ruby-lang.org/issues/16175#change-81682 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- 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: