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.
Abigail
Thread Previous
|
Thread Next