FAQ
# New Ticket Created by Father Chrysostomos
# Please include the string: [perl #128241]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=128241 >


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

Search Discussions

  • Father Chrysostomos via RT at May 26, 2016 at 5:01 am

    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=128241
  • Demerphq at May 26, 2016 at 2:45 pm

    On 26 May 2016 01:01, "Father Chrysostomos via RT" 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.perl.org/Ticket/Display.html?id=128241
  • Demerphq at May 26, 2016 at 2:50 pm

    On 26 May 2016 10:45, "demerphq" wrote:
    On 26 May 2016 01:01, "Father Chrysostomos via RT" 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.perl.org/Ticket/Display.html?id=128241
    R
  • Abigail at May 26, 2016 at 4:00 pm

    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
  • Demerphq at May 26, 2016 at 5:39 pm

    On 26 May 2016 11:59 a.m., "Abigail" 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
  • Abigail at May 26, 2016 at 10:34 pm

    On Thu, May 26, 2016 at 07:39:07PM +0200, demerphq wrote:
    On 26 May 2016 11:59 a.m., "Abigail" 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
  • Aristotle Pagaltzis at May 26, 2016 at 8:44 pm
    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/>
  • Smylers at May 27, 2016 at 8:43 am

    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
  • Aristotle Pagaltzis at May 27, 2016 at 10:21 am

    * Smylers [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/>
  • Smylers at May 27, 2016 at 11:25 am

    Aristotle Pagaltzis writes:

    * Smylers [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
  • Aristotle Pagaltzis at May 27, 2016 at 12:03 pm

    * Smylers [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/>
  • Zefram at May 27, 2016 at 1:19 pm

    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
  • Abigail at May 27, 2016 at 10:48 am

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedMay 26, '16 at 4:56a
activeMay 27, '16 at 1:19p
posts14
users6
websiteperl.org

People

Translate

site design / logo © 2018 Grokbase