From: eregontp@... Date: 2016-11-29T20:40:00+00:00 Subject: [ruby-core:78424] [Ruby trunk Feature#12979] Avoid exception for #dup on Integer (and similar cases) Issue #12979 has been updated by Benoit Daloze. Mike Vastola wrote: > Nobuyoshi Nakada wrote: > > I remember `clone` has `freeze` option. > > What should `1.clone(freeze: false)` do, ignore the option, or raise an `ArgumentError`? > > This is totally beside the point. `1.clone(freeze: false)` does not do what you say. The keyword :freeze has default value true for #clone, which means if the original object is frozen so will be the clone. See #12300 for details. Since `freeze: false` that can be considered as an explicit request to get a clone/copy, to modify it and re-freeze it later, it seems reasonable to raise in such a strange case. But, no harm could be done to immediate always-frozen objects anyway, so it would also be harmless to ignore the option IMHO. OTOH I agree `1.clone(freeze: false)` is confusing and the behavior not intuitive from the syntax/names. Maybe `1.clone(freeze_clone: false)` or `1.clone(propagate_freeze: false)` or so would be clearer. But this should be discussed in #12300 then. ---------------------------------------- Feature #12979: Avoid exception for #dup on Integer (and similar cases) https://bugs.ruby-lang.org/issues/12979#change-61796 * Author: Martin D��rst * Status: Open * Priority: Normal * Assignee: Nobuyoshi Nakada ---------------------------------------- This is a proposal resulting from a discussion in Bug #11929. Because this is proposing a different solution from #11929, it has a new number. #11929 shows that people are confused that e.g. 3.dup throws an exception (but Integer#dup is actually implemented, so Integer.respond_to? :dup => true). Integer#dup should fail silently, returning the receiver, in the same way as Integer#freeze fails silently. Citing from #11929 (comment by Mike Vastola): "If the object can't be duped/cloned because it's an immediate, dup/clone should return the object itself. (There shouldn't be any harm in doing so since nothing about the object can be changed in the first place.)". Citing some more: > I literally can't imagine any scenario in which a dev, when, say, coding a class with the line: > > return val.dup.freeze > .. really wants an Exception thrown when val happens to be de-facto un-dup-able. What they really want is: > > return val.dup.freeze rescue val The proposal also has the advantage that it leads to a much more unified, streamlined protocol, avoiding needless exposition of internals. It would do exactly what dup (and clone) are described to do, namely (pretend to) return a shallow copy. -- https://bugs.ruby-lang.org/ Unsubscribe: