> -----Ursprüngliche Nachricht----- > Von: Weinand Bob [mailto:bobw...@hotmail.com] > Gesendet: Mittwoch, 22. Oktober 2014 16:16 > An: Dmitry Stogov > Cc: Andrea Faulds; PHP Internals > Betreff: Re: [PHP-DEV] [RFC] Safe Casting Functions > > If we really want an integer at all price we just can use a simple (int) > cast. That’s AFAIK not the point of this RFC. > > And at that point where we can add a default as second parameter, we also > just can use NULL with ??. The latter is at the > same time more powerful and less restrictive. > > Also, with a second parameter, we don’t have any possibility to check if the > conversion was successful or if the fallback was > used. > > Bob
I believe the point of this RFC is to have save casts in the sense of a type-safe casts. Under this circumstances I would give this RFC a +1 In my opinion, and as mentioned by Dmitry, the only way to achieve this is using exceptions (or triggering an E_RECOVERABLE_ERROR) when something fails. Consider the following example: $total = to_int($_GET['a']) + to_int($_GET['b']); Regardless whether false or NULL is returned, total will be 0 and the error will be ignored. I think that should not be the purpose of this RFC. Otherwise it is merely another way of casting. Sure, introducing safe casts does not free the user from input validation (and I merely used $_GET as an example) but that is another topic. I am sure someone will argue now that if the user validates the input anyway then such safe casts are not necessary. I would argue that they are still useful and necessary when not even mandatory. Personally, I would only use to_int. Even in cases where I believe to know that the input is valid by design (say it comes from a config file) because you never know if someone (a hacker) was not able to manipulate your config value and thus can exploit your code in some way or the other. I cannot come up with a concrete scenario but I guess you get my point. If in such a case an exception is thrown then the request terminates unexpected but for the better. Cheers, Robert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
