Feature #12979

Avoid exception for #dup on Integer (and similar cases)

Added by duerst (Martin Dürst) almost 4 years ago. Updated about 3 years ago.

Target version:


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.

Related issues

Related to Ruby master - Bug #11929: No programatic way to check ability to dup/clone an objectClosedmatz (Yukihiro Matsumoto)Actions
Related to Ruby master - Feature #13985: Avoid exception for #dup/#clone on Rational and ComplexClosedActions

Also available in: Atom PDF