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

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.

  • Comment on Re^9: rv of list assignment (was "map in void context")

Replies are listed 'Best First'.
Re^10: rv of list assignment (was "map in void context")
by pat_mc (Pilgrim) on Dec 22, 2008 at 23:47 UTC
    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.