tc39/proposal-rm-builtin-subclassing

Use case for overriding RegExp#exec (Type IV)

Opened this issue · 1 comments

Subclassing RegExp and overriding exec is extremely useful for extending ECMAScript regular expressions. I think previous issues have pointed out that this is used by Babel. Another (new) library doing this is regex (relevant code from v4.0.0 here). regex does this to support transpiling extended regex syntax for atomic groups and regex subroutines (from PCRE, Perl, etc.) into native JS regexes. Emulating these features requires the addition of "emulation groups" that add anonymous capturing groups to a regex but should not affect the results of regex matches (e.g. they should not affect backreferences in the replacement strings/callbacks of String#replace/replaceAll, nor should they add to result arrays from RegExp#exec or String#match/matchAll, nor alter the results of String#split).

Subclassing RegExp and overriding exec is also useful in backcompat libraries for polyfilling named capturing as well as flags /y and /d. And it will likely be useful for pollyfilling future RegExp flags and syntax. Essentially, it's a great way to make all regex and regex-using methods benefit from the polyfill, rather than having to reimplement much slower versions of all of the methods.

The readme for this proposal currently makes it sound like overriding exec is asking for a bad time, but it’s actually amazingly easy to use (e.g., see the code I linked to earlier).

I agree and feel the type IV example would be better addressed by instead changing re.test(str) to directly return re.exec(str) != null and dropping all the symbol methods.