@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.
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)
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) 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?
Updated by 
Updated by 
Updated by 
Updated by 
Updated by