in reply to Re^2: Find Number in String then Ignore Characters proceeding
in thread Find Number in String then Ignore Characters proceeding

(Unfortunately, the straightforward attempt  $str =~ s/[+-](\d+).{\1}//g; doesn't work.)
How come the straight forward way doesn't work?

Because the regex compiler will attempt to compile the entire  [+-](\d+).{\1} regex (the 'search' regex of the substitution) at compile time, but the  \1 backreference of the  .{\1} counted quantifier sub-expression is not known until run time, when something may be captured that it can actually refer back to. OTOH, the  (??{".{$1}"}) 'postponed' extended pattern is specifically designed to both compile and run at run-time.

BTW: The use of  $^N is, IMHO, 'safer' than the use of  $1 in the sub-expression  (??{ ".{$1}" }) (making it  (??{ ".{$^N}" }) instead) because  $^N equals the contents of the most recently closed capturing group and will not change (semantically) if the relative positional relationship between that capture group and the use of  $^N does not change; whereas adding another capture group anywhere before the  (\d+) group will change the semantics of  $1 because capture group counting will change.

Replies are listed 'Best First'.
Re^4: Find Number in String then Ignore Characters proceeding
by Eliya (Vicar) on May 29, 2012 at 23:44 UTC
    ...but the \1 backreference of the .{\1} counted quantifier sub-expression is not known until run time, when something may be captured that it can actually refer back to

    I think it's worth pointing out that in other cases this works just fine.  For example, in /(\d+) \1/, a placeholder for the captured value is compiled into the regex.  I.e., the following will match

    print "123 123" =~ /(\d+) \1/ ? "matched" : "didn't match";

    It's just that with more complex patterns, it doesn't seem to be implemented. (I don't see any compelling reason why - in principle - the count in question here couldn't just as well be compiled to refer to a captured value.)