Hi! >> Wait, we actually already have FILTER_VALIDATE_INT and >> FILTER_VALIDATE_FLOAT, > > Actually, to_int is very close to FILTER_VALIDATE_INT, and I’m not > sure, but I think to_float may be close to FILTER_VALIDATE_FLOAT. The > main difference with integers is rejection of whitespace and > toString-able objects.
So essentially we have a number of rules, which all are only slightly different. And when somebody wants to skip spaces, but not tabs, we'd have yet another set of functions? I don't think it's good for the language to have a set of functions doing exactly the same, but in slightly different way, because some people had different preferences. The language should not be just a bag of use-cases that somebody wanted to implement. We're getting a lot of criticism for parts of the language not always playing cohesively together, why make it worse? > The main point of the RFC is to add casting functions as an > alternative to the built-in explicit casts. Currently, the easiest > way to convert to an integer is (int), but this is quite dangerous as > it performs no validation whatsoever and cannot fail. to_int() and So, why not have filter_var($suspected_int, FILTER_VALIDATE_INT) and filter_var($suspected_int, FILTER_CONVERT_INT)? We already have infrastructure for that, why ignore it completely and build another solution that does exactly the same but treats whitespace differently and has couple of other tweaks? OK, you want to treat the whitespace differently, I get it - but why ignore whole filter infrastructure? > the like are intended to be just as convenient as an explicit cast, > so that doing the safer thing (failing on garbage input) is not any > more difficult. The hope is that the lazy developer will use is_int() > instead of (int) when they need to explicitly cast, and avoid the > problems of the latter. The lazy developer won't check the return value anyway and would get 0 as the result of false-to-int conversion, thus making the whole exercise pointless anyway :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
