On 26/01/2026 08:46, Alexandre Daubois wrote:
Le ven. 23 janv. 2026 à 18:46, Rowan Tommins [IMSoP]
<[email protected]> 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]
