On Thu, Jan 27, 2011 at 02:38:56PM +0000, Ed Avis wrote: > Leon Timmermans <fawaka <at> gmail.com> writes: > > >[cases where evaluating ($b + 0) changes the value of a later expression] > > >I think the real bug here is not that a scalar value can have both a > >numeric and a string value, but that some operators and keywords are > >polymorphic on the representation of the value. > > Well, perhaps. But practically, I do not suggest changing either of > those things. It is not a problem that a scalar can have both a > numeric and a string value. What is wrong is that the scalar can > somehow be altered just by using it in an expression, without > assigning to it or using any other explicit mutation operator. Its > values, whatever they may be, should stay the same when you just read > it. > > >From a practical point of view, changing all the operators which > depend on the representation of a value might be a big task, but > changing ($b + 0) so that it just looks at the value of $b, but > doesn't alter it, seems like a smaller fix. The problem with ($b + 0) is that it *cannot* just look at the value of $b, if all that $b contains is a string. While you can in Perl, you cannot add strings and integers in the underlaying machinery. And you aren't seriously suggesting that: $b = "foo"; $a = $b + 0; say $a; should print "foo", are you? Now, whether or not the numified value should be cached, and if it's being cached, whether it should be done as it's now, is a different question. But people have been coping with this for the past couple of decades. I don't think anyone is willing to design and implement a change like this. AbigailThread Previous | Thread Next