On 13 July 2010 13:43, Ben Morrow <ben@morrow.me.uk> wrote: > Quoth demerphq@gmail.com (demerphq): >> On 12 July 2010 20:30, Dave Mitchell <davem@iabyn.com> wrote: >> > On Mon, Jul 12, 2010 at 06:06:15PM +0200, Reini Urban wrote: >> >> gvsv is just checking magic and doing the sideeffect >> > >> > Huh? gvsv doesn't call magic. >> > >> > Also, just as a data point, note that pp_concat *explicitly* calls get >> > magic twice on $a . $a: >> > >> > if (left == right) >> > /* $r.$r: do magic twice: tied might return different 2nd time */ >> > SvGETMAGIC(right); >> >> Id like to argue that this was misguided. I dont think we guarantee >> any particular order in this case for the fetch calls and thus the >> statement is /still/ undefined even with this change. > > Perl doesn't have undefined behaviour. No matter what weasel words > copied from stdc made it into the ++ docs, Perl's actual evaluation > order has always been straightforward and well-defined. Changing this > may be worth it, for a sufficiently beneficial optimisation, but it is > definitely a backwards-incompatible change. Just so everyone can conveniently see: From perldoc perlop: Auto-increment and Auto-decrement "++" and "--" work as in C. That is, if placed before a variable, they increment or decrement the variable by one before returning the value, and if placed after, increment or decrement after returning the value. $i = 0; $j = 0; print $i++; # prints 0 print ++$j; # prints 1 Note that just as in C, Perl doesn’t define when the variable is incremented or decremented. You just know it will be done sometime before or after the value is returned. This also means that modifying a variable twice in the same statement will lead to undefined behaviour. Avoid statements like: $i = $i ++; print ++ $i + $i ++; Perl will not guarantee what the result of the above statements is. If we are going to say that these statements are well defined then we should probably document exactly what the rules are, as well as correcting the above docs. Ill just say that in this case I would much prefer we dont change the documentation, except to make this much more prominent in the Tie and Overload documentation. There is more benefit for more people if we can take advantage of the undefinedness than there is harm done to people doing naughty things like this despite the documentation (they are saved only by the lack of prominence of this documentation). cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next