On 13/07/2014 15:41, Zeev Suraski wrote:
In other words, if someone types in '12a' (by mistake or intentionally), I think it's a very sane behavior to just treat it as 12, as opposed to forcing me (the developer) to write error handling code with a try/catch block, and a fairly hairy try/catch block too.
Sure, but what if they type 'abc'? You *might* want that to be cast as 0 (not for an age input, obviously, but perhaps a "minimum price" field), so you could argue for *always* casting, rather than erroring. On the other hand, you might well want to default to some other value, which would require custom handling somewhere.
If you want to allow for people *accidentally* adding letters, why accept '12a' but not 'a12'? If you want a "best guess", surely both should come out as 12 (whereas an integer cast would give you 0 for the latter). If you want validation, both are equally invalid.
To my mind, the more values are let through with a bit of hand-waving, the less useful the check is. The worst culprit for this is is_numeric(), which sounds like a useful general-purpose function, but will happily accept exotic numbers like '-1e-10', and thus is almost never what you want.
Your example of "12 " (that I didn't even think about before) is an even a more likely scenario, but I think there's no strong reason not to allow both.
I disagree, and think there's a stronger argument to be made for handling whitespace as a special case. Notably, int casts already do so - (int)' 12' (leading space) is 12, but (int)'a12' (leading non-digit) is 0 (no such special case is needed for trailing whitespace, because any trailing characters are ignored.)
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
