Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129936
Precedence: list
MIME-Version: 1.0
References: <CAMU7ir+1VfQCiSVG0BjN5V+upNU2kU+a_rKDXO1=Ahu3ndmOGg@mail.gmail.com>
 <CANS-=pfCasTNSAMSdL8ajJMnrwNpfvbEOoQTQhAQ=X73iG+_tw@mail.gmail.com>
 <CAMU7irLgsMCzHsQDD6Ok2zJZsNyV7LF-PHotzqvSGRAkN9bovg@mail.gmail.com>
 <31563ed1-ac44-47ef-9fca-3ebbfc567ba5@sandfox.me> <CAMU7irLSn2KhhyFotxaqBTS6MYiHmEZH69gAELXrmRRvKHZLqA@mail.gmail.com>
 <8A9F3BDD-1C65-4E6F-BD65-C43F017D52E2@rwec.co.uk> <CAMU7ir+JvXsEM4CM_VthUKXi_8G4W+6b+Z7BBTuQRCHbgM7Qzw@mail.gmail.com>
 <85c420f7-38ba-46f6-b434-addb733d023d@rwec.co.uk>
In-Reply-To: <85c420f7-38ba-46f6-b434-addb733d023d@rwec.co.uk>
Date: Tue, 27 Jan 2026 15:37:34 +0700
Message-ID: <CAEZPtU50e-CLEzWH_ZXEp2UcEPENf_9Hr28bksy0+E2xRFRU-Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate Fuzzy Type Casts and Allow Stringable
 in Strict Mode
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: pierre.php@gmail.com (Pierre Joye)

Hello Rowan, Alexandre, and all :)

On Tue, Jan 27, 2026 at 1:45=E2=80=AFAM Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:
>
> On 26/01/2026 08:46, Alexandre Daubois wrote:
>
> Le ven. 23 janv. 2026 =C3=A0 18:46, Rowan Tommins [IMSoP]
> <imsop.php@rwec.co.uk> a =C3=A9crit :
>
> 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 s=
yntax 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 part=
s:
>
>
> 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 '+'? lea=
ding space? trailing space? leading zeroes? trailing zero decimal part? tra=
iling non-zero decimal part? other trailing characters?
>
> PHP has a bunch of different versions of these rules used in different co=
ntexts, 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 TypeE=
rror. But that's not the only reasonable option - you might just a boolean =
(true=3Dvalid, false=3Dinvalid); or you might want to substitute a default =
value.
>
> In the case of the "(int)" syntax, I would argue that the established beh=
aviour 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,
--=20
Pierre