develooper Front page | perl.perl5.porters | Postings from October 2015

Re: YA smartmatch proposal

Thread Previous | Thread Next
From:
Abigail
Date:
October 13, 2015 16:43
Subject:
Re: YA smartmatch proposal
Message ID:
20151013164305.GB7595@almanda.fritz.box
On Tue, Oct 13, 2015 at 05:15:58PM +0100, Dave Mitchell wrote:
> On Tue, Oct 13, 2015 at 11:13:25AM -0400, Eric Brine wrote:
> > On Mon, Oct 12, 2015 at 6:17 AM, Dave Mitchell <davem@iabyn.com> wrote:
> > 
> > > On Wed, Oct 07, 2015 at 07:07:53PM +0200, Lukas Mai wrote:
> > > > This would mean 'when (qr/.../)' becomes 'when { $_ eq qr/.../ }'.
> > >
> > > Good point. So a literal qr// will have to be accepted as well as a
> > > literal //, perhaps along with a warning that "given(qr/.../) better
> > > written as given(/.../)" ?
> > >
> > 
> > Why?
> 
> Because its inefficient. It has to clone a new regex each time. Its like
> doing sub {...}->(...) rather than f(...).
> 
> > "split(qr{...}, ...)" doesn't warn, and I use that whenever I want a
> > delimiter other than "/".
> 
> Why not use m{....} ?
> 
> > Even "$_ =~ qr{...}" doesn't warn.
> 
> Yes, it's too late to change that. But if I had a time machine, I would
> have added such a warning when qr// was introduced. But since this is new
> (kinda), we have the opportunity to add a new warning without backcompat
> issues.


Instead of warning, can't it be optimized? I mean, if there's logic 
that determines "I'm now going to clone a regex, which I will throw
away right away, so let's warn", can't it just not clone the regexp,
and act as m{}?



Abigail

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About