Proposal for exact matching and matching at a position in RegExp

Mike Samuel mikesamuel at
Sun Feb 14 15:23:25 PST 2010

2010/2/15 Steve L. <steves_list at>:
> On Feb 14, 2010, at 1:40 AM, Brendan Eich wrote:
>>> compatibility with other regex flavors is probably good enough  reason to
>>> chose \G over /y.
>> Not clear, since ES3 deviated from Perl and will not reconverge. The
>> committee is not going to standardize any lastIndex or pos mapping per
>> target string and regex pair, I am pretty sure.
> That seems a reasonable position for the committee to take. To be clear, are
> you suggesting that \G be ruled out, but leaving the door open for
> standardizing /y?
>> Perhaps with enough string- and byte-buffer performance, the JS  library
>> ecosystem can promulgate a new class, call it RegEx, which has  the best
>> consensus API, and built-in RegExp can try to fade away.
> That would be quite interesting to see, but since there are just a few,
> mostly tolerable design issues with the existing ES RegExp API, I can only
> envision a switch to a JS library over built-in RegExp being justified if
> the library included pretty much all the features of ES regexes and added
> significant new features including better Unicode support. In the near term,
> the resulting file size would pretty much assure low adoption in
> browser-land.

If one of the features that you're concerned about is a convenient
literal syntax, then the quasis strawman could fill that gap.

> Since I don't have much hope for a reasonable alternative to RegExp, I think
> it's important to continue looking at RegExp improvements for future ES
> versions. I have a laundry list of desired changes and additions, but the
> three things I'd like to see first are /x, /y, and atomic groups. But now
> I'm off topic again, so I'll just leave it there. :)
> Steven Levithan
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list