regular expression addition - lookbehind assertions and lookahead assertions

[liamquin]

look-ahead assertions are i think the most useful things not found in qt regular expressions, and also look-behind.

This lets you do things like

  replace( ., '
     / ( [^/]+ ) (*positive_lookahead: /)
    ', '...', 'x')

replacing components between /..../ but not consuming the trailing /, so that
/a/b/c/d/ comes out as /../../../../

Perl uses
(?=pattern), (*pla:pattern), (*positive_lookahead:pattern)
(?!pattern), (*nla:pattern), (*negative_lookahead:pattern)
to match only if the pattern is (or is not) followed by a match to pattern,

and
(?<=pattern), \K, (*plb:pattern), (*popsitive_lookbehind:pattern)
(?<!pattern), (*nlb:pattern), (*negative_lookbehind:pattern)
for zero-width look-behind assertions.

Note, libpcre (and older Perl version) restrict lookbehind assertions to fixed length. You can write
(?<=dog|cat) food
to match " food" preceded by "dog" or "cat", but you cannot write
(?<=dogs?|cats?) barking

\C is also forbidden, as are capturing subgroups. But the facility is still very useful, and reduces the need for repeated substitutions.

I propose adding only the first form in each case, not the newer "*" forms, which are less widely supported.

[michaelhkay]

This sounds feasible to me, though it's a fair bit of work (on specification, tests, and implementation). I suggest we restrict it so that (a) lookbehind has to be fixed length, and (b) neither lookahead nor lookbehind allows capturing groups.

Lookbehind syntax uses the < character which will make it rather inconvenient, especially as &-escaping inside string literals is recognized (and required) in XQuery but not in XPath. Perhaps we should allow leftwards arrow (U+2190) as an alternative.

[liamquin]

We could use the *plb *pla *nlb *nla syntax instead of < maybe, or even the longer versions ("terseness shall not be a goal" hah).

The restrictions are OK if sometimes a pain; i think libpcre has them too.

You’ve been wanting to use non-ASCII characters for yonks, now’s the chance :-) but i’d rather use something people have a chance of looking up online, so i'd go for (*posivitve-lookbehind-assertion:foo) i think.

People already have trouble with { } in regular expressions, it’s an excellent point.