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 --- via perlbug: queue: perl5 status: new https://rt.perl.org/Ticket/Display.html?id=128241Thread Next