From @cpansprout

It often comes up on the list that /$foo/ is subject to re-use of the last match if $foo is empty, and most people then admit that it was a mistake, and that the last match should be used only when the // is syntactically empty. (I believe we have consensus on this, but I may be mistaken.)

Because of backward-compatibility, we cannot simply change it, but we could emit a deprecation warning whenever /$foo/ uses the last successful match.

I suspect this will catch many bugs in people’s code. After the deprecation cycle, we can make /$foo/ behave the same way as /(?​:$foo)/.

--

Father Chrysostomos

From @cpansprout

On Wed May 25 21​:55​:41 2016, sprout wrote​:

It often comes up on the list that /$foo/ is subject to re-use of the
last match if $foo is empty, and most people then admit that it was a
mistake, and that the last match should be used only when the // is
syntactically empty. (I believe we have consensus on this, but I may
be mistaken.)

Because of backward-compatibility, we cannot simply change it, but we
could emit a deprecation warning whenever /$foo/ uses the last
successful match.

I suspect this will catch many bugs in people’s code. After the
deprecation cycle, we can make /$foo/ behave the same way as
/(?​:$foo)/.

I forgot to mention. Anyone who intentionally wants /$foo/ to use the previous match will also get the deprecation warning and change the code to do it some other way.

That said, we might want to change /$foo/ without a deprecation cycle, since almost every use of it to mean last-successful-match is probably a bug. This should probably be done early in the dev cycle.

In ticket #128225, Yves Orton wrote​:

Fwiw i dont buy the back compat argument on this
one. I have never seen this feature deliberately
used, most people are unaware of it and when they
discover it they consider it a bug like in this
thread. In fact the only time I have seen it used
is in toy code that I wrote to demonstrate the
feature. I am convinced that nobody would notice
and that the *many* issues that have come from it
over the years justifies removing it entirely.

Are you referring to the removal of // as referring to the last successful match? I am strongly opposed to that, but I don’t mind changing /$foo/-as-last-match, without a deprecation cycle, if we do it soon.

--

Father Chrysostomos

The RT System itself - Status changed from 'new' to 'open'

From @demerphq

On 26 May 2016 01​:01, "Father Chrysostomos via RT" <
perlbug-followup@​perl.org> wrote​:

On Wed May 25 21​:55​:41 2016, sprout wrote​:

It often comes up on the list that /$foo/ is subject to re-use of the
last match if $foo is empty, and most people then admit that it was a
mistake, and that the last match should be used only when the // is
syntactically empty. (I believe we have consensus on this, but I may
be mistaken.)

Because of backward-compatibility, we cannot simply change it, but we
could emit a deprecation warning whenever /$foo/ uses the last
successful match.

I suspect this will catch many bugs in people’s code. After the
deprecation cycle, we can make /$foo/ behave the same way as
/(?​:$foo)/.

I forgot to mention. Anyone who intentionally wants /$foo/ to use the
previous match will also get the deprecation warning and change the code to
do it some other way.

That said, we might want to change /$foo/ without a deprecation cycle,
since almost every use of it to mean last-successful-match is probably a
bug. This should probably be done early in the dev cycle.

In ticket #128225, Yves Orton wrote​:

Fwiw i dont buy the back compat argument on this
one. I have never seen this feature deliberately
used, most people are unaware of it and when they
discover it they consider it a bug like in this
thread. In fact the only time I have seen it used
is in toy code that I wrote to demonstrate the
feature. I am convinced that nobody would notice
and that the *many* issues that have come from it
over the years justifies removing it entirely.

Are you referring to the removal of // as referring to the last
successful match?

Yes.

I am strongly opposed to that,

Ok. But

but I don’t mind changing /$foo/-as-last-match, without a deprecation
cycle, if we do it soon.

--

Father Chrysostomos

---
via perlbug​: queue​: perl5 status​: new
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=128241

From @demerphq

On 26 May 2016 10​:45, "demerphq" <demerphq@​gmail.com> wrote​:

On 26 May 2016 01​:01, "Father Chrysostomos via RT" <
perlbug-followup@​perl.org> wrote​:

On Wed May 25 21​:55​:41 2016, sprout wrote​:

It often comes up on the list that /$foo/ is subject to re-use of the
last match if $foo is empty, and most people then admit that it was a
mistake, and that the last match should be used only when the // is
syntactically empty. (I believe we have consensus on this, but I may
be mistaken.)

Because of backward-compatibility, we cannot simply change it, but we
could emit a deprecation warning whenever /$foo/ uses the last
successful match.

I suspect this will catch many bugs in people’s code. After the
deprecation cycle, we can make /$foo/ behave the same way as
/(?​:$foo)/.

I forgot to mention. Anyone who intentionally wants /$foo/ to use the
previous match will also get the deprecation warning and change the code to
do it some other way.

That said, we might want to change /$foo/ without a deprecation cycle,
since almost every use of it to mean last-successful-match is probably a
bug. This should probably be done early in the dev cycle.

In ticket #128225, Yves Orton wrote​:

Fwiw i dont buy the back compat argument on this
one. I have never seen this feature deliberately
used, most people are unaware of it and when they
discover it they consider it a bug like in this
thread. In fact the only time I have seen it used
is in toy code that I wrote to demonstrate the
feature. I am convinced that nobody would notice
and that the *many* issues that have come from it
over the years justifies removing it entirely.

Are you referring to the removal of // as referring to the last
successful match?

Yes.

I am strongly opposed to that,

Ok. But

We should definitely deprecate it and then remove it (for real).

Fwiw have you ever used it or seen it used?

but I don’t mind changing /$foo/-as-last-match, without a deprecation
cycle, if we do it soon

Yeah. I agree that is less controversial.

Fwiw One problem i have with this misfeature is that the pattern to split
does not follow the same rule as a normal match.

--

Father Chrysostomos

---
via perlbug​: queue​: perl5 status​: new
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=128241
R

From @Abigail

On Thu, May 26, 2016 at 04​:50​:04PM +0200, demerphq wrote​:

Fwiw have you ever used it or seen it used?

I've seen it used, and I have used it myself.

Having said that, I personally, am not going to miss it if it
were to be removed.

But I'm neutral on the question whether it should be removed.

Abigail

From @demerphq

On 26 May 2016 11​:59 a.m., "Abigail" <abigail@​abigail.be> wrote​:

On Thu, May 26, 2016 at 04​:50​:04PM +0200, demerphq wrote​:

Fwiw have you ever used it or seen it used?

I've seen it used, and I have used it myself.

Interesting. Would i be correct in thinking the place you saw it used was
in a s///?

Having said that, I personally, am not going to miss it if it
were to be removed.

But I'm neutral on the question whether it should be removed.

Abigail

From @ap

Personally​:

• I agree /$empty/ should be deprecated.

• I oppose changing its behaviour without a deprecation cycle.

• I would enjoy seeing // as “last successful pattern” gone entirely
  someday as a matter of taste, but I now believe this is a bridge too
  far past necessity.

  Consider that qr// already does not mean to use the last successfully
  matched pattern – it just always matches. If /$empty/ is also changed,
  then there is no way to accidentally trigger that behaviour during an
  attempt to compose or pass around a pattern. The only way to get that
  behaviour would be with a literal // in the program source.

  At that point, the special case is so well circumscribed that I see
  no real gain in excising it entirely, however ancient-Unix-warty it
  may be.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

From @Abigail

On Thu, May 26, 2016 at 07​:39​:07PM +0200, demerphq wrote​:

On 26 May 2016 11​:59 a.m., "Abigail" <abigail@​abigail.be> wrote​:

On Thu, May 26, 2016 at 04​:50​:04PM +0200, demerphq wrote​:

Fwiw have you ever used it or seen it used?

I've seen it used, and I have used it myself.

Interesting. Would i be correct in thinking the place you saw it used was
in a s///?

It's been a long time ago since I saw it, so I'm hazy on the details,
but I don't think it was in a s///. (Unless you could vi, where I
use this all the time).

I have used // (not inside s///) myself, although I cannot remember
why or how. I just remember thinking "this is the first time I have
a use for //".

Abigail

From @Smylers

Aristotle Pagaltzis writes​:

Personally​:

• I agree /$empty/ should be deprecated.

• I oppose changing its behaviour without a deprecation cycle.

“Warning​: We've found a bug in your code. Please fix it now, otherwise a
future version of Perl will automatically fix it for you.”

At that point, the special case is so well circumscribed that I see
no real gain in excising [use of literal //] entirely, however
ancient-Unix-warty it may be.

Would it have advantages for users of the identically spelt //
defined-or operator? Specifically, are there circumstances where
somebody who makes a mistake while trying to use defined-or could get an
error message but at the moment gets mysterious repeat-match behaviour?
Or does get an error message, but a suboptimal one?

Smylers
--
http​://twitter.com/Smylers2

From @ap

* Smylers <Smylers@​stripey.com> [2016-05-27 11​:21]​:

Aristotle Pagaltzis writes​:

Personally​:

• I agree /$empty/ should be deprecated.

• I oppose changing its behaviour without a deprecation cycle.

“Warning​: We've found a bug in your code. Please fix it now, otherwise
a future version of Perl will automatically fix it for you.”

“Warning​: we’ve found behaviour in your code that is almost certainly
a bug. If by any chance it is not, then you need to fix your code now.
Otherwise you can turn off this warning and carry on.”

Although this does raise a very good point​: how? In previous threads
about this I proposed a ${^LAST_MATCHED_PATTERN} (or whatever its name)
which would be a qr object.

(At which point it becomes conceivable to eventually remove the special
case entirely, since there is another exactly equivalent way of getting
it. But I still don’t think it would be a worthwhile gain.)

At that point, the special case is so well circumscribed that I see
no real gain in excising [use of literal //] entirely, however
ancient-Unix-warty it may be.

Would it have advantages for users of the identically spelt //
defined-or operator? Specifically, are there circumstances where
somebody who makes a mistake while trying to use defined-or could get
an error message but at the moment gets mysterious repeat-match
behaviour? Or does get an error message, but a suboptimal one?

a) Just taking your questions at face value – I don’t think so. Have you
  experienced something like that? (Not rhetorical.) I cannot say that
  I have, myself.

  I am not aware of any context where // is ambiguous as to whether it
  means defined-or or empty match. All of the ways I can think of to
  accidentally get a match when one wanted a defined-or boil down to
  forgetting to type the variable in an expression, which is a type of
  mistake I believe I have not made even once in my entire programming
  life. Hence, presumably, why I’ve never run into such a case.

b) Your questions seem moot in the first place, though.

  Are you proposing to make // not even parse as a match literal at all
  any more? Then consider what that would do to `$foo =~ //`. The error
  would be something like “operand missing”. That is the opposite of an
  improvement. I would oppose that proposal.

  If you merely wanted to remove the special case behaviour entirely,
  that expression would still have to parse as an empty match literal
  and only then – maybe – warn that that is a useless operation. So the
  fact that // means a match literal in some contexts and defined-or in
  others would still remain, which means in that case your questions
  are based on a faulty premise.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

From @Abigail

On Fri, May 27, 2016 at 09​:43​:30AM +0100, Smylers wrote​:

Aristotle Pagaltzis writes​:

Personally​:

• I agree /$empty/ should be deprecated.

• I oppose changing its behaviour without a deprecation cycle.

“Warning​: We've found a bug in your code. Please fix it now, otherwise a
future version of Perl will automatically fix it for you.”

At that point, the special case is so well circumscribed that I see
no real gain in excising [use of literal //] entirely, however
ancient-Unix-warty it may be.

Would it have advantages for users of the identically spelt //
defined-or operator? Specifically, are there circumstances where
somebody who makes a mistake while trying to use defined-or could get an
error message but at the moment gets mysterious repeat-match behaviour?
Or does get an error message, but a suboptimal one?

That seems unlikely. I don't see any obvious way to get Perl confuse a
binary operator with a term. Perhaps sometime, a single person has once
written a program intending to use // where Perl is using repeat-match
and he/she never noticed this when running the program. And while he/she
may benefit if he/she gets to upgrade the perl used, it seems to far
fetched to count as an argument to eliminate the use of repeat-match.

Abigail

From @Smylers

Aristotle Pagaltzis writes​:

* Smylers <Smylers@​stripey.com> [2016-05-27 11​:21]​:

Aristotle Pagaltzis writes​:

Personally​:

• I agree /$empty/ should be deprecated.

• I oppose changing its behaviour without a deprecation cycle.

“Warning​: We've found a bug in your code. Please fix it now,
otherwise a future version of Perl will automatically fix it for
you.”

“Warning​: we’ve found behaviour in your code that is almost certainly
a bug. If by any chance it is not, then you need to fix your code now.

Well it isn't really fix; it's more like make a change in order to keep
it working.

Otherwise you can turn off this warning and carry on.”

Except the bug hasn't been fixed yet, so it'd make more sense to
actually fix it now, but you could change it back to what it currently
is after the following upgrade.

Most deprecation cycles are to give users advance warning of a change
that they need to make so their code will work as intended with future
versions of Perl. Given “almost certainly a bug”, a deprecation cycle
here would give users advance warning that their code will start working
as intended in the future but it doesn't do that yet so for now they
should make a temporary change (that they can later change back).

That seems like more hassle on users than a typical deprecation warning.
Or at least a different sort of hassle.

Is that really worth it for the sake of genuine uses of /$empty/, who we
don't know even exist at all?

Although this does raise a very good point​: how?

  if ($pattern eq '') { // } else { /$pattern/ }

Not elegant, but it is at least possible (so long as literal //
remains), which should be sufficient for removing /$empty/.

At that point, the special case is so well circumscribed that I
see no real gain in excising [use of literal //] entirely,

Would it have advantages for users of the identically spelt //
defined-or operator? Specifically, are there circumstances where
somebody who makes a mistake while trying to use defined-or could get
an error message but at the moment gets mysterious repeat-match
behaviour? Or does get an error message, but a suboptimal one?

a) Just taking your questions at face value – I don’t think so.

Fair enough.

Have you experienced something like that? (Not rhetorical.)

I can't remember doing — but then I generate coding errors with
sufficient abundance that it outstrips my ability to remember all of
them.

I am not aware of any context where // is ambiguous as to whether it
means defined-or or empty match. All of the ways I can think of to
accidentally get a match when one wanted a defined-or boil down to
forgetting to type the variable in an expression, which is a type of
mistake I believe I have not made even once in my entire programming
life.

I think it's well within my bounds of ineptness to mistakenly turn a
line like this​:

  my $variable = some_long_function_name($with, $various, $args);

into this​:

  my $variable = some_long_function_name($with, $various, $args);
  // 'sensible_default';

while initially failing to remove the semicolon at the end of the first
line.

Currently that yields the error message​:

  String found where operator expected at slash_slash line 4,
  near "// 'sensible_default'"
  (Missing operator before 'sensible_default'?)
  syntax error at slash_slash line 5, near "// 'sensible_default'"
  Execution of slash_slash aborted due to compilation errors.

Whereas using || instead of // (to get an idea of the type of error
message // could give if it didn't have two roles) gives​:

  syntax error at bar_bar line 5, near "||"
  Execution of bar_bar aborted due to compilation errors.

The // message is a little confusing, in that it's complaining about a
missing operator at a point where there very much looks to be an
operator (but presumably Perl has interpreted as a repeated match).
Arguably the || message is less misleading, but probably not that much
more helpful to a beginner.

b) Your questions seem moot in the first place, though.

Are you proposing to make // not even parse as a match literal at all
any more?

I'm not proposing anything; I was simply wondering whether there are any
potential advantages in removing //, beyond ‘it's a misfeature that we
wish hadn't been introduced in the first place’.

Smylers
--
http​://twitter.com/Smylers2

From @ap

* Smylers <Smylers@​stripey.com> [2016-05-27 13​:39]​:

Otherwise you can turn off this warning and carry on.”

Except the bug hasn't been fixed yet

D’oh.

so it'd make more sense to actually fix it now, but you could change
it back to what it currently is after the following upgrade.

Yeah, awkward.

That seems like more hassle on users than a typical deprecation
warning. Or at least a different sort of hassle.

Is that really worth it for the sake of genuine uses of /$empty/, who
we don't know even exist at all?

The reason for my discomfort is that this change in behaviour can easily
lead to silent data corruption if the code was previously correct, and
even in cases where the sudden difference in behaviour gets noticed, it
may be very hard to track down what caused it. So I would not want that
change made without giving sufficient notice that it’s coming.

But you are right that it’s less than obvious how to do this coherently.

Hmm.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

From zefram@fysh.org

Aristotle Pagaltzis wrote​:

I am not aware of any context where // is ambiguous as to whether it
means defined-or or empty match.

"int // - $z" could be parsed as either "int(// - $z)" or "int() //
(-$z)". It actually parses as the former, but if "//" is replaced with
"||" then it parses the latter way. So presumably if "//" ceased to be
a valid term, then it would change the parsing here, making it consistent
with "||".

-zefram

From @iabyn

On Fri, May 27, 2016 at 02​:03​:05PM +0200, Aristotle Pagaltzis wrote​:

* Smylers <Smylers@​stripey.com> [2016-05-27 13​:39]​:

Otherwise you can turn off this warning and carry on.”

Except the bug hasn't been fixed yet

D’oh.

so it'd make more sense to actually fix it now, but you could change
it back to what it currently is after the following upgrade.

Yeah, awkward.

That seems like more hassle on users than a typical deprecation
warning. Or at least a different sort of hassle.

Is that really worth it for the sake of genuine uses of /$empty/, who
we don't know even exist at all?

The reason for my discomfort is that this change in behaviour can easily
lead to silent data corruption if the code was previously correct, and
even in cases where the sudden difference in behaviour gets noticed, it
may be very hard to track down what caused it. So I would not want that
change made without giving sufficient notice that it’s coming.

But you are right that it’s less than obvious how to do this coherently.

Another possibility is to change the behaviour now, but also warn
whenever the changed behaviour is encountered. For these two scenarios​:

1. The user's code is currently buggy (it expects /$empty/ to be like /(?​:)/)

Formerly their code would quietly fail; in future their code will noisily
succeed. They can update their code to either​: disable the warning; or if
they want their code to run on older perls, to fix it to be portable.

2. The user actually wanted the 'last regex' behaviour on /$empty/​:

Formerly, their code worked;
in future their code fails, but with a noisy warning, alerting them that
their code needs fixing on newer perls.

And just to recap, IIUC, the current proposal for this ticket is to;

1) leave literal // with its 'last regex' behaviour for now.
2) change /$empty/ behaviour, with the exact details on deprecation and
warnings to be decided.

--
Counsellor Troi states something other than the blindingly obvious.
  -- Things That Never Happen in "Star Trek" #16

From @demerphq

On 11 Jul 2016 10​:13, "Dave Mitchell" <davem@​iabyn.com> wrote​:

On Fri, May 27, 2016 at 02​:03​:05PM +0200, Aristotle Pagaltzis wrote​:

* Smylers <Smylers@​stripey.com> [2016-05-27 13​:39]​:

Otherwise you can turn off this warning and carry on.”

Except the bug hasn't been fixed yet

D’oh.

so it'd make more sense to actually fix it now, but you could change
it back to what it currently is after the following upgrade.

Yeah, awkward.

That seems like more hassle on users than a typical deprecation
warning. Or at least a different sort of hassle.

Is that really worth it for the sake of genuine uses of /$empty/, who
we don't know even exist at all?

The reason for my discomfort is that this change in behaviour can easily
lead to silent data corruption if the code was previously correct, and
even in cases where the sudden difference in behaviour gets noticed, it
may be very hard to track down what caused it. So I would not want that
change made without giving sufficient notice that it’s coming.

But you are right that it’s less than obvious how to do this coherently.

Another possibility is to change the behaviour now, but also warn
whenever the changed behaviour is encountered. For these two scenarios​:

1. The user's code is currently buggy (it expects /$empty/ to be like
/(?​:)/)

Formerly their code would quietly fail; in future their code will noisily
succeed. They can update their code to either​: disable the warning; or if
they want their code to run on older perls, to fix it to be portable.

2. The user actually wanted the 'last regex' behaviour on /$empty/​:

Formerly, their code worked;
in future their code fails, but with a noisy warning, alerting them that
their code needs fixing on newer perls.

And just to recap, IIUC, the current proposal for this ticket is to;

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.

2) change /$empty/ behaviour, with the exact details on deprecation and
warnings to be decided.

--
Counsellor Troi states something other than the blindingly obvious.
-- Things That Never Happen in "Star Trek" #16

From @cpansprout

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.

--

Father Chrysostomos

From @cpansprout

On Mon Jul 11 07​:13​:28 2016, davem wrote​:

Another possibility is to change the behaviour now, but also warn
whenever the changed behaviour is encountered. For these two
scenarios​:

1. The user's code is currently buggy (it expects /$empty/ to be like
/(?​:)/)

Formerly their code would quietly fail; in future their code will
noisily
succeed. They can update their code to either​: disable the warning; or
if
they want their code to run on older perls, to fix it to be portable.

2. The user actually wanted the 'last regex' behaviour on /$empty/​:

Formerly, their code worked;
in future their code fails, but with a noisy warning, alerting them
that
their code needs fixing on newer perls.

I think that sounds like a good idea. Are you volunteering? :-)

And just to recap, IIUC, the current proposal for this ticket is to;

1) leave literal // with its 'last regex' behaviour for now.
2) change /$empty/ behaviour, with the exact details on deprecation
and
warnings to be decided.

Yes, that was the idea.

--

Father Chrysostomos

From @iabyn

On Mon, Jul 11, 2016 at 08​:35​:18AM -0700, Father Chrysostomos via RT wrote​:

I think that sounds like a good idea. Are you volunteering? :-)

Yes, but not immediately.

--
This email is confidential, and now that you have read it you are legally
obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have
received this email in error, place it in its original wrapping and return
for a full refund. By opening this email, you accept that Elvis lives.

From @ap

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2016-07-11 17​:36]​:

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.

I went back and forth over this a bit.

My initial inclination was the same as yours​: the less special a special
case is, the better.

But when I imagined making that claim, I realised it doesn’t really help
in his situation​: we already have a special case, and you just have to
memorize what works where. There already isn’t much systematic about it.

And in a way it could even be easier to understand and explain if the
reuse-last-pattern thing was a feature of s/// and didn’t clog the rest
of the documentation. There would be just one kind of operation where
you ever saw this in code, and it would look suitably odd to signal that
something unusual is going on (“how could a substitution of nothing have
an effect?”) and the documentation for that operation is the place that
would explain it. Simple and coherent and discoverable. It almost makes
the feature sound like a good idea!

But my next realisation was that we’re not in a vacuum​: code may have to
work across Perl versions. And documentation has to explain the issues
relating to that. Both tasks are easier if divergences are kept small.

So ultimately I think adding reuse-last-pattern as a special feature of
s/// (and s///) alone would make sense if we were starting from scratch,
but keeping it in m// is preferable given that we do have a historical
context and that the context is what it is.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

From @demerphq

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