Proposal for exact matching and matching at a position in RegExp

[Brendan Eich]

On Feb 14, 2010, at 6:04 AM, Steve L. wrote:

> 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?

Yes, I think \G without full Perl compatibility is less desirable  
than /y -- but I would want some solution here, and it should be on  
the Harmony agenda.

Perhaps we need you to seed that agenda. Start a new thread to remind  
us of your 95, or just 5 (I hope ;-), theses nailed to the ES3  
cathedral door.


>> 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.

Yes, it's a long term hope, or possibly dream.


> 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. :)

To fuel this fire (separate thread is fine, all your theses at once), / 
x already caused ES4 headaches which Waldemar argued are insuperable,  
to-do with semicolon insertion.

/be