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


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

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>

[download]

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

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

Replies are listed 'Best First'.
Re^3: ${^POSTMATCH} problem
by ikegami (Patriarch) on Jun 14, 2020 at 15:34 UTC

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

    [download]

    But now, it's roughly equivalent to 

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

    [download]

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

[reply]
[d/l]
[select]
      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

[reply]

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

[reply]

In Section Seekers of Perl Wisdom