Misc #17412
closedRegexp vs Range: freezing differences
Description
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.
Updated by mame (Yusuke Endoh) about 4 years ago
- 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:
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.
Updated by zverok (Victor Shepelev) about 4 years ago
Thanks for the explanation!
Updated by ko1 (Koichi Sasada) about 4 years ago
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!!).
Updated by Eregon (Benoit Daloze) about 4 years ago
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).
Updated by Eregon (Benoit Daloze) about 4 years ago
- Related to Feature #8948: Frozen regex added
Updated by Eregon (Benoit Daloze) almost 2 years ago
- Related to Feature #17256: Freeze all Regexp objects added