Front page | perl.perl5.porters |
Postings from June 2016
Re: RFC: deprecate quantifying zero-length constructs in regexpatterns
Thread Previous
|
Thread Next
From:
Abigail
Date:
June 3, 2016 10:06
Subject:
Re: RFC: deprecate quantifying zero-length constructs in regexpatterns
Message ID:
20160603100813.GB8504@almanda.fritz.box
On Thu, Jun 02, 2016 at 11:05:56AM +0100, Smylers wrote:
> 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.
While you can disable warnings when you are generating the patterns,
you don't always have control over the point it's being used.
Specially not if your pattern generating stuff is in separate module.
And not all generated patterns will be generated as qr // constructs.
I very often generate them as strings.
(Ergo, I'm not too much of a fan of these warnings).
Abigail
Thread Previous
|
Thread Next