in reply to Re^7: rv of list assignment (was "map in void context")
in thread map in void context

Thanks, ikegami, for the clear proof that indeed the side effect of list assignment is that a list of all values assigned is returned!

This is a consistent extension of the behaviour of the assignment operator in scalar context and exactly in line with what I would have expected.

To re-state my point: ikegami's code only works because of the side-effects associated with the assignment operator (To my personal surprise, ikegami mentioned earlier in this thread that
Side-effects are something to be avoided when programming.
  • Comment on Re^8: rv of list assignment (was "map in void context")

Replies are listed 'Best First'.
Re^9: rv of list assignment (was "map in void context")
by tilly (Archbishop) on Dec 22, 2008 at 09:17 UTC
    Avoiding side-effects does not mean not understanding them. And we may use techniques in example code that we avoid in production code.
Re^9: rv of list assignment (was "map in void context")
by ikegami (Patriarch) on Dec 22, 2008 at 13:29 UTC

    That's not what I said it returns. You ignored half the answer. Whatever you claimed to have proven probably wasn't.

    To my personal surprise, ikegami mentioned earlier in this thread that

    You can't use a different definition of "side-effects" and assume what other people said about them still applies. According to the definition I was using, the assignment has no side-effects. But I'm fine with with what I said even when using the functional programming definition. It's not that the assignment operators shouldn't be used, it's that creating operators and subs with side-effects should be done with care.

      Apologies if I misquoted you ...
      my $x = ($a,$b) = (4,5,6); # $x = 3
      indeed shows that list assignment has several side-effects, one in list context and another one in scalar context (I, personally, dislike that ... I think the behaviour in scalar context should be consistent with that in list context).

      On first reading of your response I had overlooked that only two elements get assigned - otherwise a return value of '3' would simple have been the size of the list of assigned elements and all would have been consistent between list and scalar context.

      This makes matters slightly worse (in my view) since it confirms my suspicion aired earlier on in this thread: some operators may indeed have more than one side-effect.