Feature #17256: Freeze all Regexp objects

• Status: Closed
• Assignee: matz (Yukihiro Matsumoto)
• Target version: -

[ko1 (Koichi Sasada)]

To be shared between ractors, Regexp objects should be frozen.

Now, Matz has proposed to make all Regexp objects frozen.

Ten months ago, there was a note https://bugs.ruby-lang.org/issues/16377#note-7 :

For the record: Regexp.new should continue to return unfrozen Regexp instance.

So I'm not sure whether it is a good way or not.

Could you give me your comment on it?

If no comments are given, I'll try to freeze them before Ruby 3.0 preview 2.

BTW, I believe /#{expr}/o should be frozen because this expression only returns one Regexp object.

[ko1 (Koichi Sasada)]

• Description updated (diff)

[ko1 (Koichi Sasada)]

• Description updated (diff)

[sawa (Tsuyoshi Sawada)]

• Description updated (diff)

[ko1 (Koichi Sasada)]

I tried it and several errors are observed on tests.
It is possible that people want to tweak Regexp objects (unlike Range objects).

How about to freeze literals includes /#{expr}/?
https://github.com/ruby/ruby/pull/3676
It is easy to fix by .dup method.

[Eregon (Benoit Daloze)]

@ko1 (Koichi Sasada) Could you show the errors from the tests?
Some tests are there just for regression or corner cases, I think actual user code matters far more than tests when it comes to backward-incompatible changes.
It seems odd to store anything on a Regexp.

[Dan0042 (Daniel DeLorme)]

Given that string literals with interpolation were recently unfrozen, it would appear slightly inconsistent to freeze regexp literals with interpolation.
/#{str}/ is equivalent to Regexp.new(str) so I would find it a bit weird if they had a different behavior w/r freezing. It would make more sense to say that all new regexps (including Regexp.new and Regexp.compile) are frozen. That way all constants such as UNSAFE = Regexp.new("[^#{SAFE_STRING}]", false) would be automatically ractor-safe.

And if someone really needs to modify a regexp maybe they can use dup?
rx = Regexp.new(str).dup.extend(PrintWhenMatch)

[marcandre (Marc-Andre Lafortune)]

Dan0042 (Daniel DeLorme) wrote in #note-6:

Given that string literals with interpolation were recently unfrozen, it would appear slightly inconsistent to freeze regexp literals with interpolation.

The difference is that there are many methods and usecases to mutate a String, and none that we know of to mutate a Regexp.

[ko1 (Koichi Sasada)]

ko1 (Koichi Sasada) Could you show the errors from the tests?

Sorry I lost the patch.

Anyway, at last dev-meeting, freezing all Regexp literals including dynamically created objects are accepted.
I don't have objection to freeze all regexp objects, but we need to observe the incompatibilities in existing code and I have no time to handle them. Try on 3.1 if someone can try?

[ko1 (Koichi Sasada)]

• Status changed from Open to Closed

7ad56fd87b35abf4933e0146761df91e9ec9890a

[Eregon (Benoit Daloze)]

• Related to Misc #17412: Regexp vs Range: freezing differences added

[Eregon (Benoit Daloze)]

• Related to Feature #8948: Frozen regex added

[znz (Kazuhiro NISHIYAMA)]

• Related to Bug #21558: Regexp.union with multiple regexps returns a non-shareable object (should be shareable if possible) added