Proposal for exact matching and matching at a position in RegExp

[Andy Chu]

> However, expanding the language by adding extra parameters to existing
> functions is annoying because it means you can't test for the presence
> of absence of the feature with a simple if:
>
> if (RegExp.funkyNewFunction) {
>  ...
> }

That's true, I would want to be able to test for the feature.  I think
you could do it like this:

if (new RegExp("a", "y").test("----a")) {
  ... use y
}

Although perhaps something easier like RegExp.sticky or
RegExp.feature('sticky') would be better.

> I think that using the length property on the function is going to be
> unreliable given the existing variation in those values.

Oh I didn't even know this existed.  I see that new
Regexp("").exec.length == 1.  Is this the argument length -- standard
or nonstandard?

There is still the "pos" argument to detect too.  I don't know if
there is some way of detecting to assume that you have "pos" as well
as "y".  Although it is syntactic sugar for .lastIndex, I think the
argument makes a lot more sense for the reasons in my article (not
stomping on it between matches).

Maybe RegExp.feature("pos").


> The way we do regexps in V8 the 'y' is part of the regexp and we would
> have to recompile the regexp to handle with or without 'y'.  In other
> words in our implementation we have an implict ".*?(" at the start of
> the regexp that indicates that there is a non-greedy match-anything
> before the 0th capture parenthesis.  This is a pretty fast and clean
> approach.  I think having something that matched 'the point where
> searching started' would be more flexible than the global Y flag.
> Then you could use it like '^' as one part of an alternation.   Perl
> uses \G for the same concept and I think following that would be fine.
>  To test for the presence of the feature you could use
>
> !/\Gx/.test("Gx")

So I wouldn't be opposed to having this , but not sure about the
compatibility issues.  Also I vaguely recall someone saying that ".*?"
can be trigger a slower code path than .search() in some regexp
engines.  As in, it's not trivial to get the performance right.

thanks,
Andy