Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129938
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 27 Jan 2026 10:36:58 +0100
To: internals@lists.php.net
Message-ID: <94dd62b3-7e5c-4162-9bef-042498ff7059@app.fastmail.com>
In-Reply-To: 
 <CAMU7ir+1VfQCiSVG0BjN5V+upNU2kU+a_rKDXO1=Ahu3ndmOGg@mail.gmail.com>
References: 
 <CAMU7ir+1VfQCiSVG0BjN5V+upNU2kU+a_rKDXO1=Ahu3ndmOGg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate Fuzzy Type Casts and Allow Stringable in Strict
 Mode
Content-Type: multipart/alternative;
 boundary=d93610e49f4449098d9cab6d1b4501fb
From: rob@bottled.codes ("Rob Landers")

--d93610e49f4449098d9cab6d1b4501fb
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 23, 2026, at 11:48, Alexandre Daubois wrote:
> Hello everyone,
>=20
> 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.
>=20
> RFC: https://wiki.php.net/rfc/deprecate-fuzzy-casts
>=20
> Thanks,
>=20
> =E2=80=94 Alexandre Daubois
>=20

This is interesting. As a user of non-strict mode, I rarely need casts. =
That being said, after working on tons of strict-mode code bases, this i=
s exactly the footgun I use to show how strict-mode is actually bad for =
their code base: I remove the casts and turn off strict mode, and the ap=
plication actually crashes because it was silently handling bad inputs a=
ll over the place.

Here's a pretty good example I saw a few weeks ago:

$newBalance =3D (int)$walletBalance;
$wallet->store($newBalance);
/* ... later ... */
$log->append($walletBalance); // which takes a string

Now, if this string is something like "1000; drop table money" and there=
 isn't proper injection protection... you're in for a bad day.

Without strict mode:
$wallet->store($walletBalance); // TypeError: cannot coerce string to int

That being said, I think the more proper solution is to simply remove st=
rict mode instead of making casts stricter. Why? Sometimes you actually =
do need to use a cast to force a specific type, and you want to use the =
loss of information. Like I=E2=80=99m pretty sure casting a float to an =
integer is faster than calling floor(), and you end up with an integer, =
not a float. Secondly, to properly use strict-mode, you have to religiou=
sly cast everything, which hides errors that=E2=80=99d otherwise appear.=
 But getting rid of lossy casting seems like trying to apply a tournique=
t to the wrong limb.

=E2=80=94 Rob
--d93610e49f4449098d9cab6d1b4501fb
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Fri, Jan =
23, 2026, at 11:48, Alexandre Daubois wrote:</div><blockquote type=3D"ci=
te" id=3D"qt" style=3D""><div>Hello everyone,</div><div><br></div><div>B=
efore going further with our already under discussion RFC about</div><di=
v>nullable casts, Nicolas Grekas and I would like to present this new</d=
iv><div>RFC about deprecating fuzzy casts, and adding support for String=
able</div><div>in string parameters when using strict mode.</div><div><b=
r></div><div>RFC:&nbsp;<a href=3D"https://wiki.php.net/rfc/deprecate-fuz=
zy-casts">https://wiki.php.net/rfc/deprecate-fuzzy-casts</a></div><div><=
br></div><div>Thanks,</div><div><br></div><div>=E2=80=94 Alexandre Daubo=
is</div><div><br></div></blockquote><div><br></div><div>This is interest=
ing. As a user of non-strict mode, I rarely need casts. That being said,=
 after working on tons of strict-mode code bases, this is exactly the fo=
otgun I use to show how strict-mode is actually bad for their code base:=
 I remove the casts and turn off strict mode, and the application actual=
ly crashes because it was silently handling bad inputs all over the plac=
e.</div><div><br></div><div>Here's a pretty good example I saw a few wee=
ks ago:</div><div><br></div><div>$newBalance =3D (int)$walletBalance;</d=
iv><div>$wallet-&gt;store($newBalance);</div><div>/* ... later ... */</d=
iv><div>$log-&gt;append($walletBalance); // which takes a string</div><d=
iv><br></div><div>Now, if this string is something like "1000; drop tabl=
e money" and there isn't proper injection protection... you're in for a =
bad day.</div><div><br></div><div>Without strict mode:</div><div>$wallet=
-&gt;store($walletBalance); // TypeError: cannot coerce string to int<br=
></div><div><br></div><div>That being said, I think the more proper solu=
tion is to simply remove strict mode instead of making casts stricter. W=
hy? Sometimes you actually do need to use a cast to force a specific typ=
e, and you want to use the loss of information. Like I=E2=80=99m pretty =
sure casting a float to an integer is faster than calling floor(), and y=
ou end up with an integer, not a float. Secondly, to properly use strict=
-mode, you have to religiously cast everything, which hides errors that=E2=
=80=99d otherwise appear. But getting rid of lossy casting seems like tr=
ying to apply a tourniquet to the wrong limb.</div><div><br></div><div i=
d=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--d93610e49f4449098d9cab6d1b4501fb--