Issue #19344 has been reported by zverok (Victor Shepelev). ---------------------------------------- Feature #19344: Regexp.new: stricter handling of second argument https://bugs.ruby-lang.org/issues/19344 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- Since Ruby 3.2 (#18788), the second argument to `Regexp.new` can be: 1. Integer: then it is treated as a combination of `Regexp::<constant>` flags 2. String: then it is treated as a combination of string flags 3. `nil` or `false`: then it is ignored 4. **any other truthy value**: then it is treated as an "ignore case" option. The fourth one is confusing, especially since the introduction of the flexibility of flags: one might erroneously assume or forget the protocol, and the naive check will strengthen the assumption: ```ruby # maybe it accepts the array of string options?.. Regexp.new('foo', %w[i]) #=> /foo/i -- oh, seems it does # would the symbol work?.. Regexp.new('foo', :i) #=> /foo/i -- awesome, it works! ``` I propose to change (4) to only handle literal `true` value, and raise `TypeError` on any unsupported type. On compatibility: I believe that whenever the usage of boolean to distinguish "ignore case/respect case" is deliberate (like [in rubygems](https://github.com/rubygems/rubygems/blob/master/lib/rubygems/optparse/lib/o...)), the code already passes true/false, not any random value. Otherwise, the change in Ruby 3.2 might also have broken it (what if it previously passed strings, meaning them to be "truthy values"?) PS: BTW, the documentation for (4) was completely lost in Ruby 3.2, due to [this PR](https://github.com/ruby/ruby/pull/5815). cc @jeremyevans0, @burdettelamar -- https://bugs.ruby-lang.org/