Proposal for exact matching and matching at a position in RegExp

[Brendan Eich]

On Feb 13, 2010, at 12:14 AM, Steve L. wrote:

> \G and ^ become more dissimilar conceptually when \G is not used as  
> the leading element. With or without /m, ^ can be thought of as a  
> one-character lookbehind that doesn't need to know the current  
> search position index. With something like /\d|\G\w/ or the  
> contrived /(?=(x?))\1\G\w/ (equivalent to /(?>x?)\G\w/ or /\G[^ 
> \Wx]/), however, the regex pattern must be aware of its start  
> position within the target string. I think this sort of mental model  
> is commonly used, and it's because \G is harder to sync with this  
> model that that I'm comfortable with introducing /y even though it  
> ignores the prior art and greater flexibility of \G. But then,  
> 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.

By starting from Perl 4 (my fault, it was 1997), then upgrading to  
Perl 5 with differences due to the need to specify what was codified  
quirkily only in perl source code, while also trying only in places to  
deal with Unicode well, we have painted ourselves into a corner.

Perl 6 of course breaks compatibility utterly, and good for it.  
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.

Anyway, when adding /y, we reckoned it was better to keep being  
different than to try \G and invite complaints that we weren't the  
same as the "genetic parent", Perl. Mutation is a bitch, and we're  
quite the red-headed stepchild now ;-).

/be