Misc #17412: Regexp vs Range: freezing differences

• Status: Closed
• Assignee: -

[zverok (Victor Shepelev)]

While working on the changelog, I noticed the following in the 3.0:

/foo/.frozen?  # => true 
(1..3).frozen? # => true 

# but...
Regexp.new('foo').frozen? # => false 
# ...whereupon
Range.new(1, 3).frozen?   # => true 

I'd like to understand, what is there a reason for non-literal regexps to not being frozen, and for ranges to be?
Corresponding tickets (#16377 and #15504) doesn't clarify the reasoning:

For the record: Regexp.new should continue to return unfrozen Regexp instance. (@mame (Yusuke Endoh) at #16377#note-7)

and:

I'm for freezing all Ranges, not only Range literals. I hate the idea of freezing only literals because casually mixing frozen and unfrozen objects leads to hard-to-debug bugs that depend upon data flow. (@mame (Yusuke Endoh) at #15504#note-3)

I understand that the matter is probably negligible, but will be very grateful for some explanations.

[mame (Yusuke Endoh)]

• Status changed from Open to Closed

Hi,

zverok (Victor Shepelev) wrote:

For the record: Regexp.new should continue to return unfrozen Regexp instance. (@mame (Yusuke Endoh) at #16377#note-7)

This is not my opinion but Matz's decision. I'm sorry if I was not clear.

I'm for freezing all Ranges, not only Range literals. I hate the idea of freezing only literals because casually mixing frozen and unfrozen objects leads to hard-to-debug bugs that depend upon data flow. (mame (Yusuke Endoh) at #15504#note-3)

This is just my opinion.

---

The difference of the two decisions is whether we find a real-world example affected by the changes.
@ko1 (Koichi Sasada) found a real-world code that defines a singleton method on a Regexp instance in the Ruby's test framework:

https://github.com/ruby/ruby/blob/648bbfcc65ad28841db2206513375dd88f064c52/tool/lib/test/unit.rb#L130

And matz decided that only Regexp literals are frozen. In practical, freezing Regexps is needed for Ractors, and freezing only Regexp literals is considered useful enough for Ractors.
(I personally don't like it very much, but I'm not against the decision.)

In regards to Ranges, we don't know any real-world case affected by the change yet.
Matz said "Since there's possiblity of breakage, I'd like to experiment it." He may revert the change if someone reports any case broken by this change (before the official releases). But so far, no breakage is reported.

[zverok (Victor Shepelev)]

Thanks for the explanation!

[ko1 (Koichi Sasada)]

More correctly, I don't want to debug (or get complaint) world-wide Regexp modifying code.
For 3.1, we can try if someone has a passion.

BTW, for the keyword parameter changes, many people work a lot (especially @mame (Yusuke Endoh) and @jeremyevans0 (Jeremy Evans)) to support many ruby gems and rubyist (Thank you so much!!).

[Eregon (Benoit Daloze)]

FWIW, I think all Regexp objects should be frozen (https://bugs.ruby-lang.org/issues/8948#note-16).
TruffleRuby will probably try this, because mixing immutable & mutable Regexps is leading to many complications when considering code sharing (e.g., multiple Ruby VMs in one process).

[Eregon (Benoit Daloze)]

• Related to Feature #8948: Frozen regex added

[Eregon (Benoit Daloze)]

• Related to Feature #17256: Freeze all Regexp objects added