Forbid implementations from extending the RegExp grammar.

Benjamin Gruenbaum benjamingr at
Mon Jul 6 14:13:14 UTC 2015

This isn't really about `RegExp.escape` as an issue. We can always extend
`RegExp.escape` when we make additions to the RegExp grammar as a standard
that would not be a problematic issue since we can keep both parts in sync
relatively easily.

On the other hand currently implementations are allowed to diverge in their
regular expressions which means there is no guarantee that they'll behave
the same in some cases. This is really risky for standard behavior and if
an implementation decides to use the clause it could create a big pain
point for developers while keeping it compliant.

Luckily, implementors are insightful people and implementations don't do
that because of precisely those usability implications for end developers.

What I'm suggesting is that we forbid implementations from extending the
regular expressions grammar *beyond the language specification and outside
the process*. Basically, we take the ECMAScript regular expression object
as specified (minus allowing extensions) as our base line :)


On Mon, Jul 6, 2015 at 5:03 PM, C. Scott Ananian <ecmascript at>

> I think it would be more worthwhile of we tried to draw a compatibility
> boundary.  Taking perlre as a baseline, for example, are there additional
> characters we should escape in `RegExp.escape` so that implementations (and
> the language itself) could add more perlre features without breaking
> compatibility?  The `(?...)` syntax (and flags) seems to be the de facto
> extension point, can we protect that more narrowly?
>   --scott
> On Jul 6, 2015 1:56 AM, "Benjamin Gruenbaum" <benjamingr at> wrote:
>> So, following work on RegExp.escape [1] I found out that implementations
>> may extend the regular expression grammar in JavaScript [2]. However, when
>> asking esdiscuss and Stack Overflow about it [2][3] it doesn't look like
>> any implementations currently do so (*).
>> Can we please forbid implementations from extending the regular
>> expression syntax? It seems like this could cause compatibility issues
>> between implementations anyway. We have subclassable RegExp with hooks and
>> symbols in place and implementations that want to provide an extended
>> RegExp can subclass RegExp or propose an extension to the language itself.
>> [1]
>> [2]
>> [3]
>> (*) some did it to implement ES2015 features before ES2015.
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list