On Friday, 23 January 2026 at 10:51, Alexandre Daubois <[email protected]> wrote:
> Hello everyone, > > Before going further with our already under discussion RFC about > nullable casts, Nicolas Grekas and I would like to present this new > RFC about deprecating fuzzy casts, and adding support for Stringable > in string parameters when using strict mode. > > RFC: https://wiki.php.net/rfc/deprecate-fuzzy-casts > > Thanks, > > — Alexandre Daubois Hello Alexandre, I know we had some preliminary offline discussions about this RFC, but having the final document in front of me, I feel you are mixing 3 different RFCs in one. And none of them are fully fleshed out within this single document. I see that you've already replied to Larry that you're going to spin out the Stringable change into its own RFC, which I think is good. However, even when just talking about the casting operators the discussion is muddled. You are grouping the transformation between scalar types (string, int, float, bool) and how they can truncate/coerce data with a possible loss of information on one hand, and talking about the (object) cast on the other hand, which is a cast to a "structured" type. While I agree that the (object) cast is definitely strange on scalar types, I also don't see why keeping (object) for casting arrays makes that much more sense? And why do you not talk about the (array) cast at all? Both of these casts are two sides of the same coin, and IMHO should both be deprecated outright, due to their confusing semantics. Yes, I know Symfony uses the (array) cast a lot, but the get_mangled_object_vars() function has existed long enough for it to replace the usage of (array) on objects. And even the aspect about the fuzzy casts feels incomplete to me, you do not talk about the (bool) or (string) cast (and relevant boolval()/strval() functions) are these affected by your RFC change? Because casting a float to a string depends on the precision INI setting, see: https://3v4l.org/5GJWh Which _feels_ like a fuzzy cast to me, although this is just PHP's usual float to string coercion semantics. You also mention that the `(int) 12.5` fuzzy cast is covered by my "Deprecate implicit non-integer-compatible float to int conversions" RFC [1], but this is not the case. See: https://3v4l.org/3AZOd#vnull As I specifically did *not* affect the behaviour of the casting operators in this RFC, nor in my prior "Saner numeric strings" RFC. The reason being is that many people were concerned about the impact on legacy codebase, or codebase that utilized the long-standing truncation behaviour. Moreover, at no point do you describe if NULL would still be accepted for type casting. Because if you do, then it would not follow the behaviour of scalar type checks which rejects NULL. And what would happen to these scalar casts if a different version of the "Deprecate type juggling to and from bool type within the function type juggling context" RFC [3] passes? Overall, it feels this proposal is trying to work around the "mindless" usage of strict_types, to which my opinion and solution is to just remove it. I very much understand the appeal of trying to fix the problem at the root, but I'm not sure if this would pass, considering that adding various "parse_T()" functions that exposes the ZPP behaviour might just be more sensible. Best regards, Gina P. Banyard [1] https://wiki.php.net/rfc/implicit-float-int-deprecate [2] https://wiki.php.net/rfc/saner-numeric-strings [3] https://wiki.php.net/rfc/deprecate-function-bool-type-juggling
