From: zverok.offline@... Date: 2019-09-22T09:59:55+00:00 Subject: [ruby-core:95030] [Ruby master Bug#16175] Object#clone(freeze: true) is inconsistent with Object#clone(freeze: false) Issue #16175 has been updated by zverok (Victor Shepelev). Backport set to 2.5: UNKNOWN, 2.6: UNKNOWN Subject changed from Make Object#clone(freeze: true) return frozen clone even if receiver is not frozen to Object#clone(freeze: true) is inconsistent with Object#clone(freeze: false) Tracker changed from Feature to Bug File freeze-true.patch added @jeremyevans0 thanks for your answer. Let me explain my point a bit. I come upon this inconsistency (or what **I** see as an inconsistency) when working on 2.4 version of my [RubyChanges](https://rubyreferences.github.io/rubychanges/) project. Typically, when going through the language version's changelog and trying to rationalize it, I use to find some less-documented changes which makes me providing documentation patches and clarification tickets. So, from where I am standing, the situation looks as follows: 1. The behavior is definitely an *inconsistency* (either behavioral or at least in documentation), I do believe PoLS should lead to having the symmetry or at least documenting of the lack of it. 2. As for three years since Ruby 2.4 I am the first to notice it (and even this is going through the changelog, not writing code), the problem is of pretty low priority. 3. Though, I don't really believe that having such an inconsistency is really justifiable, especially considering recent uprising of interest to immutability (and therefore freezing). 4. I don't think that "freeze cloned can be achieved with `clone.freeze`, therefore `clone(freeze: true)` is redundant" is a strong argument. For me, it looks a bit like saying "we can achieve subtraction with `x.+(-y)`, therefore `x.-(y)` is redundant": `clone(freeze: true)` looks atomic, logical and readable, I don't see why it shouldn't work. 5. OK, "We don't need it because there are other ways to achieve it" could be justifiable **if** fixing the inconsistency requires significant effort (in planning and/or implementation). For what I can see, the change is pretty trivial. Attached is the patch implementing it. It is not the prettiest code possible, but at least it allows to estimate an amount of effort. PS: I hope you will not find completely inappropriate that I've changed back the type of the issue to "Bug" and rephrased the title to show WHY I consider it so. From my perspective, it is not me requesting some new weird feature, but trying to straighten up some obvious inconsistency (even if a low-priority one). ---------------------------------------- Bug #16175: Object#clone(freeze: true) is inconsistent with Object#clone(freeze: false) https://bugs.ruby-lang.org/issues/16175#change-81660 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- 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) -- https://bugs.ruby-lang.org/ Unsubscribe: