[RFC] Deprecate Fuzzy Type Casts and Allow Stringable in Strict Mode

On Fri, Jan 23, 2026 at 11:51 AM Alexandre Daubois < alex.daubois+php@gmail.com> wrote:

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?

On 23 January 2026 10:48:45 GMT, Alexandre Daubois <alex.daubois+php@gmail.com> wrote:

Hi Alexandre, I am strongly against the Stringable part of this. It would mean users who have explicitly asked for no type coercion would get silent type coercion. It would mean that a string parameter in mode 1 would still reject an integer 42, but would *accept* new BcMath\Number(42). I can't see how that makes sense. - My thoughts on "fuzzy casts" are more nuanced. I do think PHP needs some functions or syntax for "validating" casts, but I'm not convinced they should *replace* our existing casts. Not only would it break the huge amount of code out there which assumes that a cast will always return a result rather than an error, I think that is a perfectly valid use case. It is often useful to say "take this string, and return an integer if it's int-like, or a default value of 0 if not". Although they're not perfect, that's roughly what our existing casts provide. I can see an argument for making (int)"123hello" evaluate to 0, rather than 123; but even that would be a confusing BC break for a lot of applications. As I've said elsewhere, I think the right approach to this is to design a new set of cast operations, with a more extendable syntax. They can have more clearly defined rules for "int-like string" etc, and different modes/variants for use cases like "error on failure" vs "default value on failure". Rowan Tommins [IMSoP]

On Fri, Jan 23, 2026, at 4:48 AM, Alexandre Daubois wrote:

1. This really feels like two separate RFCs. I'd rather see them as two separate RFCs than one mixed RFC. 2. I tend to agree with other commenters that we should leave the existing casts alone, and instead add a new, more reasonable type conversion operators (for some definition of reasonable). 3. Unlike the other commenters, I am 100% in favor of allowing `string` to accept Stringable in strict mode. Strict mode basically broke Stringable, and that's been an annoyance for a long time. I know some feel that Stringable is always and forever a bad thing, amen, but I don't agree. It has ample valid use cases, even if it can be abused. I want my Stringable objects back! :-) --Larry Garfield

On Friday, 23 January 2026 at 10:51, Alexandre Daubois <alex.daubois+php@gmail.com> wrote:

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

On Fri, Jan 23, 2026, at 11:48, Alexandre Daubois wrote:

This is interesting. As a user of non-strict mode, I rarely need casts. That being said, after working on tons of strict-mode code bases, this is exactly the footgun I use to show how strict-mode is actually bad for their code base: I remove the casts and turn off strict mode, and the application actually crashes because it was silently handling bad inputs all over the place. Here's a pretty good example I saw a few weeks ago: $newBalance = (int)$walletBalance; $wallet->store($newBalance); /* ... later ... */ $log->append($walletBalance); // which takes a string Now, if this string is something like "1000; drop table money" and there isn't proper injection protection... you're in for a bad day. Without strict mode: $wallet->store($walletBalance); // TypeError: cannot coerce string to int That being said, I think the more proper solution is to simply remove strict mode instead of making casts stricter. Why? Sometimes you actually do need to use a cast to force a specific type, and you want to use the loss of information. Like I’m pretty sure casting a float to an integer is faster than calling floor(), and you end up with an integer, not a float. Secondly, to properly use strict-mode, you have to religiously cast everything, which hides errors that’d otherwise appear. But getting rid of lossy casting seems like trying to apply a tourniquet to the wrong limb. — Rob