Abigail writes: > On Wed, Jun 01, 2016 at 10:56:42PM -0600, Karl Williamson wrote: > > > qr/ ^ {1,3} /x, warns with "Quantifier unexpected on zero-length > > expression" > > > > qr/ ^ * /x warns instead with "^ * matches null string many times", > > and generates code that will run a very long time. > > > > qr/ ^ ? /x doesn't warn. Nor does qr/ ^ {0,1} /x. But > > qr/ ^ {0,2} /x does warn. > > > > It is nonsensical to use a quantifier on an assertion, and for Perl > > to try to do so is not likely at all to be DWIM. So I believe we > > should deprecate these. > > I'd say it's about as nonsensical as multiplying 0 with something, or > doing C< "" x 5 >, There's sort-of a difference, in that regular expressions tend to be more line-noise-like and trip people up than basic arithmetic does. I suggest that programmers make both typos and conceptual errors with regexp patterns far more often than they accidentally multiply something by zero. > I grant you, there are many examples where it doesn't make sense, but > it makes generating patterns easier if "$SUB_PATTERN$QUANTIFIER" is > always valid, regardless whether $SUB_PATTERN is a zero-length > expression. That's an excellent reason for not deprecating, nor even discouraging, such use. How about consistently warning on all the examples Karl gave above? Anybody generating patterns from fragments who is effectively saying ‘this may be nonsensical but I don't care’ could disable the warning. Intentionally doing something potentially nonsensical is the paradigm of when it makes sense to disable a warning. And given that some of the above situations already do warn, anybody generating patterns like this probably should already be disabling relevant warnings anyway, in which case making more situations issue warnings in the same category won't affect them. Smylers -- http://twitter.com/Smylers2Thread Previous | Thread Next