Project

General

Profile

Misc #17412

Regexp vs Range: freezing differences

Added by zverok (Victor Shepelev) 2 months ago. Updated 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
[ruby-core:101549]

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.


Related issues

Related to Ruby master - Feature #8948: Frozen regexAssignedmatz (Yukihiro Matsumoto)Actions

Updated by mame (Yusuke Endoh) 2 months 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:

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.

Updated by zverok (Victor Shepelev) 2 months ago

Thanks for the explanation!

Updated by ko1 (Koichi Sasada) 2 months 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) 2 months 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).

#5

Updated by Eregon (Benoit Daloze) 2 months ago

Also available in: Atom PDF