RFC: https://wiki.php.net/rfc/deprecate-fuzzy-casts
I found additional concerns about this RFC.
Under scope, this RFC has a footnote, "Float-to-int precision loss
((int) 12.5) is covered by a separate RFC." But this is not accurate.
The referenced separate RFC is specific to implicit type casts, whereas
the Fuzzy Casts RFC is specific to explicit type casts.
This RFC ignores the case where $a = "1.5" and someone attempts (int)
$a. Even if the intent is to deprecate the current result of int(1), we
have no simple way to check this. As of v8.5, is_numeric($a) would
return true which breaks the "Validate before casting" code provided in
this RFC (it would still throw Deprecated in that case). Similarly,
is_int($a) and is_float($a) both return false for all numeric strings,
which is unhelpful here.
The next line of code under "Or use filter functions" is also
problematic. The function filter_var() does not guarantee an int return
value. Maybe I'm being overly critical, but I don't see how this can be
considered a "migration option" when it is logically incomplete. And,
if this is a serious migration path, every instance of (int) in the
world might need to be converted to something like this:
if (false === filter_var($a, FILTER_VALIDATE_INT)) $a = 0;
$result = (int) $a;
The same can be said of the PREG example in the RFC, which leaves the
$result variable unset for any string that doesn't begin with a space or
a number. Was this example intended to be used in combination with the
code above it? Are developers expected to replace a sing type cast with
8 lines of code for PHP 8.6?
_____________
Robert Chapin
