Re^4: ${^POSTMATCH} problem

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.

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}

Comment on Re^4: ${^POSTMATCH} problem

Replies are listed 'Best First'.
Re^5: ${^POSTMATCH} problem by ikegami (Patriarch) on Jun 15, 2020 at 04:22 UTC
Short of completely rewriting Perl, it would have to make an actual copy to act like it was handling copies.	[reply]
Re^6: ${^POSTMATCH} problem by ikegami (Patriarch) on Jun 15, 2020 at 04:26 UTC
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.	[reply] [d/l] [select]