On Thu, Jan 27, 2011 at 03:59:23PM -0800, Jan Dubois wrote: > On Thu, 27 Jan 2011, Ed Avis wrote: > > > > No, not at all. I don't suggest any change to the existing semantics of +, > > except that it should become side-effect-free, that is, whether you evaluate > > ($b + 0) or do not evaluate that expression should have no effect on later uses > > of $b. (Provided $b is just a plain scalar and not tied or an object, etc.) > > I would agree with this (caching converted representations should not > be detectable at the language level). Unfortunately some operations > are *documented* to behave otherwise: > > | The auto-increment operator has a little extra builtin magic to > | it. If you increment a variable that is numeric, or that has > | ever been used in a numeric context, you get a normal increment. > | If, however, the variable has been used in only string contexts > | since it was set, and has a value that is not the empty string > | and matches the pattern "/^[a-zA-Z]*[0-9]*\z/", the increment is > | done as a string, preserving each character within its range, > | with carry: > > (From perlop.pod; note the phrase "used in a numeric context") Note that the documentation the quote contains a couple of white lies. $a = "foo123"; 0 + $a; # Use the variable $a in numeric context $b = $a; $a = "bar456"; $a ++; $b ++; say $a; # Prints 'bar457'; say $b; # Prints '1'; So, we have a variable $a that's used in numeric context, and variable $b that isn't, yet $a gets the magic autoincrement, but $b doesn't. AbigailThread Previous | Thread Next