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

On 26/01/2026 08:46, Alexandre Daubois wrote:

Le ven. 23 janv. 2026 à 18:46, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> a écrit :

I don't think we should repurpose widely-used syntax for a different use case. If we want new functionality, with new semantics, we should add new syntax for that.

The rules/semantics proposed in this RFC are not new.

Hi Alexandre, In my mind, cast / type conversion behaviour can be described in two parts: The first part is the rules of which input values count as "valid". In the case of string to integer casts: can it include a leading '+'? leading space? trailing space? leading zeroes? trailing zero decimal part? trailing non-zero decimal part? other trailing characters? PHP has a bunch of different versions of these rules used in different contexts, and it would certainly be nice to make them all more consistent. The second part is the behaviour of what happens for a value which is *not* valid. In the case of parameter types and return types, this is to throw a TypeError. But that's not the only reasonable option - you might just a boolean (true=valid, false=invalid); or you might want to substitute a default value. In the case of the "(int)" syntax, I would argue that the established behaviour is that an invalid value *returns a default value* - for an integer, zero. In other words, I don't think (int)'hello' is a "fuzzy cast", it is an operator with clear and useful behaviour: reject 'hello' as input for integer, and substitute default zero. The "(int)" syntax has had that behaviour in PHP for over 20 years, and a huge amount of code has been written explicitly making use of that fact. For instance, I see this pattern a lot: $foo = (int)$_GET['foo']; if ( $foo !== 0 ) { ... } Changing the behaviour of (int) so that it throws a TypeError for invalid cases would be a hugely disruptive change, and would replace one useful feature with a different useful feature, rather than having good syntax for both. Regards, -- Rowan Tommins [IMSoP]