How should I handle regex-features labeled with "warning"?

How should I handl开发者_运维百科e regex-features labeled with "warning" like "(?{ code })", "(??{ code })" or "Special Backtracking Control Verbs"? How serious should I take the warnings?

I kinda think they’re here to stay, one way or the other — especially code escapes. Code escapes have been with us for more than a decade.

The scariness of them — that they can call code in unforeseen ways — is taken care of by use re "eval". Also, the regex matcher hasn’t been reëntrant until 5.12 IIRC, which could limit their usefulness.

The string-eval version, (??{ code }), used to be the only way to do recursion, but since 5.10 we have a much better way to do that; benchmarking the speed differences shows the eval way is way slower in most cases.

I mostly use the block-eval version, (?{ code}), for adding debugging, which happens at a different granualarity than use re "debug". It used to vaguely bother me that the return value from the block-eval version’s wasn’t usable, until I realized that it was. You just had to use it as the test part of a conditional pattern, like this pattern for testing whether a number was made up of digits that were decreasing by one each position to the right:

qr{
  ^ (
      ( \p{Decimal_Number} )
      (?(?= ( \d )) | $)
      (?(?{ ord $3 == 1 + ord $2 }) (?1) | $)
    ) $
}x

Before I figured out conditionals, I would have written that this way:

qr{
   ^ (  
        ( \p{Decimal_Number} ) 
        (?= $ | (??{ chr(1+ord($2)) }) )
        (?: (?1) | $ ) 
    ) $
}x

which is much less efficient.

The backtracking control verbs are newer. I use them mostly for getting all possible permutations of a match, and that requires only (*FAIL). I believe it is the (*ACCEPT) feature that is especially marked “highly experimental”. These have only been with us since 5.10.