From: daniel@...42.com Date: 2020-08-26T20:43:44+00:00 Subject: [ruby-core:99716] [Ruby master Bug#17030] Enumerable#grep{_v} should be optimized for Regexp Issue #17030 has been updated by Dan0042 (Daniel DeLorme). What about this? ```ruby 2.times do p $~ # depends on match *below* rx =~ str end ``` Now imagine if `2.times` is replaced by `foo`; a priori we can't know if or how many times the block will be executed. So what I was trying to say is that flow control can lead to all kinds of code paths where it's extremely difficult to know which matching operations a pseudo-global may depend on. Maybe not impossible, but personally I wouldn't want to code that kind of analysis when a simple approach is enough for >90% of cases, and guaranteed to be bug-free. > There will be other false positives: `str.gsub(regexp, &block)`. That's not a real issue, simply assume that `block` will want access to `Regexp.last_match`. Actually... `block` does not have access to `Regexp.last_match` (unless you created the block in the same scope as the gsub operation, but that would be unusual) ---------------------------------------- Bug #17030: Enumerable#grep{_v} should be optimized for Regexp https://bugs.ruby-lang.org/issues/17030#change-87206 * Author: marcandre (Marc-Andre Lafortune) * Status: Open * Priority: Normal * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Currently: ```ruby array.select { |e| e.match?(REGEXP) } # about 3x faster and 6x more memory efficient than array.grep(REGEXP) ``` This is because `grep` calls `Regexp#===` which creates useless `MatchData` -- https://bugs.ruby-lang.org/ Unsubscribe: