Proposal for exact matching and matching at a position in RegExp

[Andy Chu]

(belated followup)

> I think a lot of people (myself included) use a similar mental model,
> although it doesn't quite match the implementation details. But even
> according to this model, avoiding /y wouldn't keep ES regex flags pure as
> mere pattern attributes since ES already crossed that bridge with /g (and no
> one complains about it).

So now that Erik Corry pointed out that /y as a compilation option
matches the implementation, as mentioned I don't mind leaving it out
of the method parameters.  The "pos" is the one that still should be a
method argument.

Can we summarize this discussion on a wiki page somewhere?  I think it
more or less came to a conclusion : )

>> Though as mentioned, gracefully upgrading with ES3-5 is an issue, so I
>> could only think of .exec() and .execLeft() for a left-anchored match.
>
> Unlike execLeft, /y or \G would be useful not only with regex.exec/test, but
> also with string.match/replace/split; and all this in
> backwards-compatible fashion (unlike adding new arguments or methods). The
> name execLeft might also be misleading since I imagine it would cause global
> regexes to be lastIndex-anchored rather than left-anchored.

Yeah true.  /y works for me.  I wasn't really proposing execLeft
anymore, just considering its advantages.

> Regarding the pos and endPos arguments
> you've proposed:
>
> - An endPos argument might be useful with the replace and match methods when
> using global regexes, but it would probably have limited use-cases with exec
> and makes no sense with execLeft (assuming endPos is the last position where
> a match can start). If, rather, it's the position at or before where the
> last match must end, it would offer nothing more than a *possible* slight
> performance improvement vs. regex.execLeft(str.slice(0, endPos)). Searching
> a sliced copy of the string would actually have the potential to perform
> *better* if it prevents having to complete a slow match attempt that goes
> beyond endPos before being discarded upon completion.

The pos and endpos arguments would be synonymous with slicing the
string, but more efficient.  In fact the Python docs say explicitly
that they're equivalent.

I think so far everyone agrees with the 'pos' optimization.  I'm not
going to push for endpos but I thought I'd mention it.

> - A pos argument (which you mentioned elsewhere) is unnecessary and
> confusing for test/exec/execLeft since the lastIndex property already
> provides the same functionality (albeit with the requirement that it's used
> with a global regex). I wish exec, test, replace, and match all offered a
> pos argument and that the lastIndex property didn't exist, but that ship has
> sailed.

Well, the proposal is that pos, if passed, overrides lastIndex.  Is
there something wrong with that?

The point is that the same RegExp() instance can be used in concurrent
contexts without the stomping on lastIndex.

> I too like Python's regex methods, but I don't think that what Python does
> well here can easily be dropped on top of ES5.

Well I'm only proposing a very small subset.  And I think JS has
already admitted its influence by Python.  Putting \G in because Perl
uses it is a bad reason, since following Perl to Perl 5 regexps would
be an atrocity : )  Unless someone is seriously arguing for \G, I
think it should be ruled out.  As you mentioned, it's more complicated
to implement since \G doesn't have to be at the beginning.

thanks,
Andy