Proposal for exact matching and matching at a position in RegExp

[Steve L.]

2010/2/12 Erik Corry <erik.corry at gmail.com>:

>> Agree that \G breaks some logical barrier.  I like to have a mental
>> model of the implementation internals, and \G breaks that a bit.
>
> \G is more flexible and it is rather similar to ^ conceptually.
>
> The mental model happens to be out of sync with how regexps are
> implemented.  The implicit .*? at the start of a regexp is actually
> the fastest way to implement since you are using the fast internal
> search mechanisms that the regexp engine has rather than an external
> loop that repeatedly asks "does it match here?".

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

> Certainly if the /y variant is adopted then V8 will implement it as if
> it were specified with \G.  Ie there would be two different regexps
> behind the scenes, one with and one without /y.  This is similar to
> what would happen if you could specify /i at match time instead of
> compile time.