On Fri, Jan 23, 2026 at 11:51 AM 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 > What's the expected behavior of `(int) '001'` and `(int) 1.`? I would expect both to still be valid integers, but I can't tell from this RFC if those scenarios would be affected. The first scenario is common with "ZEROFILL" database columns, and the latter is a scenario I recently found being used to get a valid int from user input if considered number-ish and switch between whole number vs decimal behavior. I'm afraid that deprecating and eventually erroring these casts will break a lot of hard to trace legacy code, where a cast "solved" most problems, or at least did not crash things. I'm talking about values that come from automated import systems, go through dozens of layers of code that haven't been touched since php 5.2 or earlier, and eventually end up in a part where we do a cast. It was also not unthinkable that these casts were used _because_ it truncated the invalid parts, and while we could replace this with a preg_match to extract the number, I don't particularly feel like going through nearly 5k int casts in this codebase and figure out if it should change or not. Does this behavior als affect parameters being passed in a non-strict fashion? Because then I don't see a realistic migration path within the next decade for this application. On the subject of strings, I'm very afraid this will cause hidden issues. The Stringable value isn't always the value I want from an object, and with this change my IDE will no longer give an error that it's the wrong type. I foresee people throwing stringable objects into string parameters and silently causing the wrong values to be used. Especially when the __toString implementation is not within our control this will be a dangerous thing to miss. This will also silently break values being passed if the __toString implementation changes, which is going to be extremely hard to trace back like with `(string) $object`. This change also makes reviewing code more difficult as I have to know the parameter type, variable type, and what the __toString function does in order to find out if it's correct, or another value had to be passed. I feel like these 2 changes will cause big problems, way more than it's worth having them be correct. Perhaps my worries are unjustified?
