On Sun, Oct 29, 2017 at 11:23:13AM +0100, demerphq wrote: > I've tried very hard to be bug-for-bug compatible with existing behaviour. > See for example this code comment in pp_multiconcat()! > > /* special-case $tied .= $tied. > * > * For something like > * sub FETCH { $i++ } > * then > * $tied .= $tied . $tied . $tied; > * will STORE "4123" > * while > * $tied .= $tied > * will STORE "12" > * > * i.e. for a single mutator concat, the LHS is > * retrieved first; in all other cases it is > * retrieved last. Whether this is sane behaviour > * is open to debate; but for now, multiconcat (as > * it is an optimisation) tries to reproduce > * existing behaviour. > > But no doubt there will be a whole bunch of things I didn't anticipate, > and I look forward to the inevitable slew of BBC tickets. > > > But wouldn't we consider this a bug we should fix? > > $x.= EXPR; > > Should be the same as > > $x = $x . EXPR; From perlop: Assignment operators work as in C. That is, $x += 2; is equivalent to $x = $x + 2; although without duplicating any side effects that dereferencing the lvalue might trigger, such as from C<tie()>. Other assignment operators work similarly. So they're not quite the same. There are also two conceptually different activities: retrieving the lvalue or rvalue, and evaluating it. For example a tied array could return overloaded objects. So in $tied[0] = $tied[0] . $tied[1]; $tied[0] .= $tied[1]; $tied[0] .= $tied[1] . $tied[2]; trying to determine the exact number and order of FETCH(), '.'-overload and '.='-overload calls is somewhat non-obvious. -- Dave's first rule of Opera: If something needs saying, say it: don't warble it.Thread Previous | Thread Next