Issue #20944 has been updated by andrykonchin (Andrew Konchin). Subject changed from Module#set_temporary_name(nil) doesn't remove completely effect of a previous assigning a temporary name to ~~Module#set_temporary_name(nil) doesn't remove completely effect of a previous assigning a temporary name~~ Description updated Could you please close this issue? I misread the object on which `set_temporary_name` is called (nested module, but not the outer). So the current behaviour is completely correct and expected. ---------------------------------------- Misc #20944: ~~Module#set_temporary_name(nil) doesn't remove completely effect of a previous assigning a temporary name~~ https://bugs.ruby-lang.org/issues/20944#change-110936 * Author: andrykonchin (Andrew Konchin) * Status: Open ---------------------------------------- ~~The method Module#set_temporary_name` was introduced in Ruby 3.3. I've noticed a surprising behaviour when a temporary name is assigned to an anonymous module (that has nested non-anonymous modules) and then `Module#set_temporary_name` called with `nil`. The name of the nested module initially was fully qualified (e.g. `#<Module:0x000000010cc5a280>::N`) but after `set_temporary_name(nil)` call it becomes `nil`. Example (from ruby/spec): ```ruby m = Module.new module m::N; end m::N.name # => #<Module:0x...>::N m::N.set_temporary_name("fake_name") m::N.name # => "fake_name" m::N.set_temporary_name(nil) m::N.name # => nil <==== questionable behaviour ``` I would expect a nested module name to have the initial value `#<Module:0x000000010cc5a280>::N` at the end. The documentation states:
If the given name is nil, the module becomes anonymous again.
So I would expect all the effects of setting a (non-nil) temporary name should be also rolled back. Linked issue https://bugs.ruby-lang.org/issues/19521 ``` -- https://bugs.ruby-lang.org/