develooper Front page | perl.perl5.porters | Postings from July 2016

Re: [perl #128241] Deprecate (or change) /$empty_string/

Thread Previous | Thread Next
From:
demerphq
Date:
July 11, 2016 21:55
Subject:
Re: [perl #128241] Deprecate (or change) /$empty_string/
Message ID:
CANgJU+VCW5yum3GdRejnXcO2SNTM1H5bqZ-E=tx-d1bYM_t8Mw@mail.gmail.com
On 11 Jul 2016 11:27 a.m., "Father Chrysostomos via RT" <
perlbug-followup@perl.org> wrote:
>
> On Mon Jul 11 07:39:18 2016, demerphq wrote:
> > On 11 Jul 2016 10:13, "Dave Mitchell" <davem@iabyn.com> wrote:
> > > 1) leave literal // with its 'last regex' behaviour for now
> >
> > I would like to deprecate it in m// but keep it in s/// where it at
least
> > has some utility.
>
> I would prefer to keep it in both, since it makes it simpler to explain.

Well, I think the "simpler to explain boat" has long since sailed for regex
related stuff...

And I think there is a tension here, between making m// consistent in
itself, and making m// consistent with s///.

What I mean by this is I think it is easier to explain a difference between
m// and s/// than it is to explain the difference between m// and split m//
which does not have this special behavior.

I actually think we should deprecate this special behavior entirely and
replace it with a verb, like (*LAST_MATCHED_PATTERN), which would make it
more explicit and make it usable in ways that currently are not available
to us, for instance it should be possible to do something like
 /$prefix(*LAST_MATCHED_PATTERN)$suffix/.

I am really unconvinced by back-compat arguments related to this,
especially in the context of m//.

I can see little to no value to using this feature in m//, except perhaps
to do things that are nowadays much better done by using a qr//.

On the other hand, there is some tiny advantage in being able to do
something like:

if (/$complex_pattern1/ or /$complex_pattern2/ or /$complex_pattern3/) {
s//$some_replacement/;}

So if we are not to deprecate some part of this behavior it would be to
not-deprecate it in s///. But I would prefer we deprecate it outright.

By the way, this is not a new position for me. I have been wanting to get
rid of this for a long time.

Yves

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