I have some trouble understanding just what the proposal is, since the
RFC doesn't contain any examples.  But I gather that you want to usurp
*both* the (...) and the [...] notation for numeric ranges.

This would change the meaning of any code that happened to contain a
regex like this:


That seems to me like a very bad idea.  

Usurping /[...]/ isn't quite as awful an idea, since patterns like
/[12,34]/ are probably rare.  

The behavior you want is already possible without an extension:

        /(\d+\.?\d*)                          # look for a number
           (?{$1 < 37.3 || $1 > 200})         # If it's out of range
           (?!)                               # ...then backtrack

I agree that this isn't really pretty, but

1. the proposed notation is really nasty, since it overloads existing
   well-established notations, and

2. I think a better response would be to find a way to use the
   existing features with a prettier notation, since they are much
   more generally applicable than your proposed extension.

Reply via email to