Regex: How should backreferences contained in the capturing match they reference to work?

StevenLevithan steves_list at
Mon Nov 26 01:33:25 PST 2007

StevenLevithan wrote:
> liorean wrote:
>>> I think I can sum up the change I think is appropriate by these things:
>>> - undefined should be a failure to match instead of a match to the empty
>>> string
>>> - captures should only be set to undefined in two cases - when the
>>>   regex matching is started, and if inside a negative lookahead
> I am in complete agreement with liorean. The ES3 handling on these points
> is non-intuitive, non-compatible with other regex libraries, *far* less
> useful than the alternative (I could give countless examples of where the
> Perl-style handling has real-world practicality), and creates future
> compatibility issues if ECMAScript were to implement certain features from
> Perl or other Perl-derivative flavors such as capturing-group-based
> conditionals.

To support my last comment with a couple of the "countless examples", I can
point to my blog:

- If backreferences to non-participating capturing groups resulted in
failure rather than a match of the empty string, it would be possible to
mimic conditionals as shown at  . That page
presents some generalized patterns, but simpler cases can often be taken
advantage of.

- If captures were only set to undefined when the regex matching starts and
after a negative lookahead which contains captures, it would be possible to
do things like shown at  .

Those are particular things I've posted about in the past, but I run into
these spec bugs ;-) on a regular basis. I have never run into a case where I
wished for the ES3 handling of these issues.
View this message in context:
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at

More information about the Es4-discuss mailing list