Hello Rowan, Alexandre, and all :) On Tue, Jan 27, 2026 at 1:45 AM Rowan Tommins [IMSoP] <[email protected]> wrote: > > 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.
I would even say it is almost a must at this stage. The introduction of declare strict_type somehow helps a bit in the context where it is used, but overall, the cognitive weight of dealing with the casts/conversions happens is beyond any level that could make sense, no matter how I look at it. And to anyone working in the engine, runtime parts can triple that cognitive weight to carry. > 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. The implicit cast is the only one I would not change, if one chooses it, we can assume the use case is clear and the person knows what's happening. The classic example you gave with a _GET expected to be an int is one of them. And if not, well, we can't prevent anyone from shooting themselves in the knee(s). It has been mentioned in various recent RFCs that one or another operations, conversions, casts, syntax is related to another similar but should be separated RFCs. I think for a few cases, it is the case. But operations like the ones discussed here, or anything related to automatic casts/conversions, may end in a way better state if they are handled once and together. We have different paradigms in the language, and communities adopt different ones. A growing part of our users, do explicitly decide to go full typed, going beyond what php does, to avoid all these pitfalls. I do think that the amount of projects going this way will increase and that's something PHP should not ignore. Maybe it is a good time to have an actual mind-friendly, I would say, sane, typing mode across the board in an actual strong type mode for the/a next php major version? Best, -- Pierre
