Issue #12979 has been updated by Mike Vastola.


So, looking at this more closely, I'm beginning to think this issue was closed in error.

For starters, while all the "Associated revisions" are to object.c, the most recent one was [23 days ago](https://github.com/ruby/ruby/commits/trunk/object.c), after which there have been discussions about the implementation, with no follow-up comments or commits from the assigned coder.

Additionally, though the most recent commit was tagged 2.4.0 RC1, I'm not seeing any mention of this issue in NEWS or ChangeLog for 2.4.0.

Given this, as well as Kasper's comment, I'd like to go ahead and ask that this be reopened (does anyone know who I should ask?), in the hopes of (at the very least) getting clarification as to whether or not this is completed (though ideally to see this fully implemented if it truly is not).

Happy Holidays!

----------------------------------------
Feature #12979: Avoid exception for #dup on Integer (and similar cases)
https://bugs.ruby-lang.org/issues/12979#change-62214

* Author: Martin Drst
* Status: Closed
* Priority: Normal
* Assignee: Nobuyoshi Nakada
* 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.



-- 
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>