> At most, I'd remove the part that truncates numeric strings like > "123abc" and always convert them to 0, because that's almost *never* > an intended effect.
I too find it hard to think of the situation in which data must be stored, even in a temporary form, as "123abc" but is meant to be equivalent to 123. But it obviously has happened a bunch after all these years. Maybe a non-accidental example is where "123a", 123b", and "123c" are all expected to be juggled to 123 -- i.e. the code is purposely utilizing the PHP behavior in place of explicit truncation in order to group certain items together. I'm 99.999% sure I've never done this, but it would be devilishly hard to find the bugs that would come from changing this behavior. Enough that I could see it being a major event that tarnishes the release of PHP-dot-whatever-makes-this-change. I also want to point out, as I did the other month when this came up, that MySQL does autoconversion that is identical to this case [1], and with **MP pairings so absurdly common, it makes sense to keep this behavior in PHP for this reason alone. -- S. [1] SELECT '123abc' = 123 // true in MySQL (but not in all RDBMSes) > One could argue that "123" == 123 is, however. > On May 7, 2012, at 6:25 PM, Raymond Irving wrote: >> I was very surprised when I came across the == issue sometime ago. IMO >> strings should be compared as strings. They should never be converted to >> integer. >> >> >> 1=="1" // always convert the number value to a string and then >> compare it >> "foo" == 0 // should return false >> >> "123abc" == "123nth" // compare as string. Do not convert to numeric values >> >> "0"==0 // true >> 0=="0." // false >> >> PHP is great but if we can work together to remove the flaws, then we can >> make it even greater. We have to leave the past behind us and look at where >> we want PHP to be in the next 5 years >> >> >> Best regards, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
