Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129886
Precedence: list
MIME-Version: 1.0
References: <CAMU7ir+1VfQCiSVG0BjN5V+upNU2kU+a_rKDXO1=Ahu3ndmOGg@mail.gmail.com>
In-Reply-To: <CAMU7ir+1VfQCiSVG0BjN5V+upNU2kU+a_rKDXO1=Ahu3ndmOGg@mail.gmail.com>
Date: Fri, 23 Jan 2026 12:43:43 +0100
Message-ID: <CANS-=pfCasTNSAMSdL8ajJMnrwNpfvbEOoQTQhAQ=X73iG+_tw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate Fuzzy Type Casts and Allow Stringable
 in Strict Mode
To: Alexandre Daubois <alex.daubois+php@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f2e93206490cacca"
From: kjarli@gmail.com (Lynn)

--000000000000f2e93206490cacca
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 23, 2026 at 11:51=E2=80=AFAM 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
>
> Thanks,
>
> =E2=80=94 Alexandre Daubois
>


What's the expected behavior of `(int) '001'` and `(int) 1.`? I would
expect both to still be valid integers, but I can't tell from this RFC if
those scenarios would be affected. The first scenario is common with
"ZEROFILL" database columns, and the latter is a scenario I recently found
being used to get a valid int from user input if considered number-ish and
switch between whole number vs decimal behavior.

I'm afraid that deprecating and eventually erroring these casts will break
a lot of hard to trace legacy code, where a cast "solved" most problems, or
at least did not crash things. I'm talking about values that come from
automated import systems, go through dozens of layers of code that haven't
been touched since php 5.2 or earlier, and eventually end up in a part
where we do a cast. It was also not unthinkable that these casts were used
_because_ it truncated the invalid parts, and while we could replace this
with a preg_match to extract the number, I don't particularly feel like
going through nearly 5k int casts in this codebase and figure out if it
should change or not.

Does this behavior als affect parameters being passed in a non-strict
fashion? Because then I don't see a realistic migration path within the
next decade for this application.

On the subject of strings, I'm very afraid this will cause hidden issues.
The Stringable value isn't always the value I want from an object, and with
this change my IDE will no longer give an error that it's the wrong type. I
foresee people throwing stringable objects into string parameters and
silently causing the wrong values to be used. Especially when the
__toString implementation is not within our control this will be a
dangerous thing to miss. This will also silently break values being passed
if the __toString implementation changes, which is going to be extremely
hard to trace back like with `(string) $object`. This change also makes
reviewing code more difficult as I have to know the parameter type,
variable type, and what the __toString function does in order to find out
if it's correct, or another value had to be passed.

I feel like these 2 changes will cause big problems, way more than it's
worth having them be correct. Perhaps my worries are unjustified?

--000000000000f2e93206490cacca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jan 23,=
 2026 at 11:51=E2=80=AFAM Alexandre Daubois &lt;<a href=3D"mailto:alex.daub=
ois%2Bphp@gmail.com">alex.daubois+php@gmail.com</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">Hello everyone,<br>
<br>
Before going further with our already under discussion RFC about<br>
nullable casts, Nicolas Grekas and I would like to present this new<br>
RFC about deprecating fuzzy casts, and adding support for Stringable<br>
in string parameters when using strict mode.<br>
<br>
RFC: <a href=3D"https://wiki.php.net/rfc/deprecate-fuzzy-casts" rel=3D"nore=
ferrer" target=3D"_blank">https://wiki.php.net/rfc/deprecate-fuzzy-casts</a=
><br>
<br>
Thanks,<br>
<br>
=E2=80=94 Alexandre Daubois<br></blockquote><div><br></div><div><br></div><=
div>What&#39;s the expected behavior of `(int) &#39;001&#39;` and `(int) 1.=
`? I would expect both to still be valid integers, but I can&#39;t tell fro=
m this RFC if those scenarios would be affected. The first scenario is comm=
on with &quot;ZEROFILL&quot; database columns, and the latter is a scenario=
 I recently found being used to get a valid int from user input if consider=
ed number-ish and switch between whole number vs decimal behavior.<br><br>I=
&#39;m afraid that deprecating and eventually erroring these casts will bre=
ak a lot of hard to trace legacy code, where a cast &quot;solved&quot; most=
 problems, or at least did not crash things. I&#39;m talking about values t=
hat come from automated import systems, go through dozens of layers of code=
 that haven&#39;t been touched since php 5.2 or earlier, and eventually end=
 up in a part where we do a cast. It was also not unthinkable that these ca=
sts were used _because_ it truncated the invalid parts, and while we could =
replace this with a preg_match to extract the number, I don&#39;t particula=
rly feel like going through nearly 5k int casts in this codebase and figure=
 out if it should change or not.=C2=A0<br><br>Does this behavior als affect=
 parameters being passed in a non-strict fashion? Because then I don&#39;t =
see a realistic migration path within the next decade for this application.=
</div><div><br></div><div>On the subject of strings, I&#39;m very afraid th=
is will cause=C2=A0hidden=C2=A0issues. The Stringable value isn&#39;t alway=
s the value I want from an object, and with this change my IDE will no long=
er give an error that it&#39;s the wrong type. I foresee people throwing st=
ringable objects into string parameters and silently causing the wrong valu=
es to be used. Especially when the __toString implementation is not within =
our control this will be a dangerous thing to miss. This will also silently=
 break values being passed if the __toString implementation changes, which =
is going to be extremely hard to trace back like with `(string) $object`. T=
his change also makes reviewing code more difficult as I have to know the p=
arameter type, variable type, and what the __toString function does in orde=
r to find out if it&#39;s correct, or another value had to be passed.</div>=
<div><br></div><div>I feel like these 2 changes will cause big problems, wa=
y more than it&#39;s worth having them be correct. Perhaps my worries are u=
njustified?</div></div></div>

--000000000000f2e93206490cacca--