[#97536] [Ruby master Bug#16694] JIT vs hardened GCC with PCH — v.ondruch@...
Issue #16694 has been reported by vo.x (Vit Ondruch).
11 messages
2020/03/18
[ruby-core:97541] [Ruby master Feature#16175] Object#clone(freeze: true) is inconsistent with Object#clone(freeze: false)
From:
eregontp@...
Date:
2020-03-19 00:57:40 UTC
List:
ruby-core #97541
Issue #16175 has been updated by Eregon (Benoit Daloze).
I'm confused, I thought `clone(freeze: true)` would be the same as `clone()`, i.e., freeze the cloned object only if the original object was frozen.
I don't think it's good to make #clone also #freeze if the original object was not frozen, that's a separate concern and out of #clone's role.
I think `obj.clone.freeze` is good enough for that use case, much clearer, and more compatible (`#initialize_clone` doesn't need to deal with this)
----------------------------------------
Feature #16175: Object#clone(freeze: true) is inconsistent with Object#clone(freeze: false)
https://bugs.ruby-lang.org/issues/16175#change-84700
* 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: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>