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


in reply to Re^2: ${^POSTMATCH} problem
in thread ${^POSTMATCH} problem

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).

Replies are listed 'Best First'.
Re^4: ${^POSTMATCH} problem
by LanX (Sage) on Jun 14, 2020 at 16:01 UTC
    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

      Short of *completely* rewriting Perl, it would have to make an actual copy to act like it was handling copies.

        No, it could also rewrite the call to join in terms of pre-multiconcat concatenation. I thought at first this would cause problems for magical vars, but that's not the case.

        But the point stands. To change this would impose a performance hit. Rather than slowing down join to provide more consistent behaviour, they've opted to speed up concatenation while providing less consistent behaviour. And I agree with this. In general, a programmer should never read and change a variable in the same statement. It introduces readability issues if nothing else, but it's common for it to invoke undefined behaviour.