http://qs321.pair.com?node_id=11118050


in reply to ${^POSTMATCH} problem

It has nothing specifically to do with POSTMATCH, you just ran into the multi-concatenation optimization.

#!/usr/bin/perl use strict; # https://perlmonks.org/?node_id=11118049 use warnings; use v5.10; sub add_incr_suffix { state $suffix = 'A'; return "prefix-TEXT-" . $suffix++; } print 'Test ' . ( add_incr_suffix =~ /^prefix-*/p ? "${^POSTMATCH}" : '' ) . "," . ( add_incr_suffix =~ /^prefix-*/p ? "${^POSTMATCH}" : '' ) . "," . ( add_incr_suffix =~ /^prefix-*/p ? "${^POSTMATCH}" : '' ) . "\n";

Here is a simpler example that produces different output under 5.26 and 5.30

#!/usr/bin/perl use strict; # https://perlmonks.org/?node_id=11118049 use warnings; my $foo; print "test: " . ($foo = 1) . ($foo = 2) . ($foo = 3), "\n";

Replies are listed 'Best First'.
Re^2: ${^POSTMATCH} problem
by LanX (Cardinal) on Jun 14, 2020 at 14:12 UTC
    Good catch!

    > It has nothing specifically to do with POSTMATCH,

    I think the crucial point is that a $variable is passed by reference (read alias)

    Compare

    DB<25> sub tt { print "@_"} DB<26> tt ( ($foo = 1) , ($foo = 2) , ($foo = 3) ) 3 3 3 DB<27>

    So the implementation of concat was changed in a function way...

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

      Yeah, The behaviour of ($foo = 1) . ($foo = 2) . ($foo = 3) used to be roughly equivalent to

      my $x = ""; $x .= ( $foo = 1 ); $x .= ( $foo = 2 ); $x .= ( $foo = 3 );

      But now, it's roughly equivalent to

      my $x = join("", ( $foo = 1 ), ( $foo = 2 ), ( $foo = 3 ), );

      In both cases, $foo itself is being put on the stack. The difference is when it's used (before it has a chance to be changed by later assignments, or after).

        I'm not happy about the behaviour of join here, because there is no way how CORE::join() will ever assign to the lvalue.

        So it should act like handling copies.

        I'm aware that we can override built-ins like join, so accessing the alias should still be possible. Theoretically that is.

        Update

        On second thought, a general new Warning in case of side effects of altered repeated variables as arguments may be more effective.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery