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

On 23 January 2026 10:48:45 GMT, Alexandre Daubois <alex.daubois+php@gmail.com> 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 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]