Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128017
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 12 Jul 2025 22:29:26 +0200
To: "Theodore Brown" <theodorejb@outlook.com>,
 "Gina P. Banyard" <internals@gpb.moe>,
 "Nicolas Grekas" <nicolas.grekas+php@gmail.com>
Cc: "PHP internals" <internals@lists.php.net>
Message-ID: <4df0afe8-9809-4420-8158-48cf633bccfd@app.fastmail.com>
In-Reply-To: 
 <BL4P223MB1364BF66B7671A923BED0FACDE4BA@BL4P223MB1364.NAMP223.PROD.OUTLOOK.COM>
References: 
 <3Yl0UGauXmKqk7s7Hqbv6iaXru-hZHf8Wj6VjwwihgRSaqZo5EZ2ndsOle-ae41C-lvnirynWt6PpuD7UJPL0zPCw18QHFE81Eb--fiiEbc=@gpb.moe>
 <bvjVobCbLKyWiVoKMNH_rtLH0_qZ5Jf2zi9FPqqpaIXNwNXi-niyI4yPc5SgLn0clNXeRvOLo0KWS2ma2o3CTMmczL5anK8G_56xi1wFegg=@gpb.moe>
 <CAOWwgpkO6CT2bD1zQ0fgg3PhmK8_TcmOpjyv3ML8HSfoFiRzsQ@mail.gmail.com>
 <XPhXQ7Qyp5Hwsr7C_2wl_trI8-M952asnpuVm_vo1ZinIovY3ecKNvR1udU_E6GHFSWnku7Na6Ig1PnaPJkLpJIbJXf_nMeBYPPulalOmYs=@gpb.moe>
 <BL4P223MB1364BF66B7671A923BED0FACDE4BA@BL4P223MB1364.NAMP223.PROD.OUTLOOK.COM>
Subject: Re: [PHP-DEV][RFC] Deprecate type juggling to and from bool type within the
 function type juggling context
Content-Type: multipart/alternative;
 boundary=d3cff7b818324346abf24501efc4bda5
From: rob@bottled.codes ("Rob Landers")

--d3cff7b818324346abf24501efc4bda5
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, Jul 12, 2025, at 01:29, Theodore Brown wrote:
> On Fri, July 11, 2025 at 05:00 G. P. Banyard wrote:
>=20
> >> On Monday, 30 June 2025 at 10:26, Nicolas Grekas wrote: =20
> >> ... =20
> >> The latter, cast-from-bool, I think they're all useful improvements=
. While most likely harmless in all the specific
> >> cases of the PR, doing e.g. an strpos() on false feels hardly legit=
. I'm therefore sympathetic to making these changes.
> >>
> >> For cast-to-bool, I'm WAY less convinced. From the PR above, explic=
it casts like "return (bool) preg_match(...)"
> >> on a method that returns a "bool" or "(bool) ($this->loggedErrors &=
 $type)" are a clear downgrade: it makes the
> >> typing PHP just more verbose without any real benefit. That doesn't=
 look worth asking the whole ecosystem to fix
> >> those deprecations. It is especially hard to see this as an improve=
ment when comparing to using the same
> >> expressions with e.g. the "if ()" operator, which doesn't need the =
explicit cast (and shouldn't of course).
>=20
> From my experience there is a very real benefit to deprecating both ca=
st-from-bool and cast-to-bool.
> Let me give an example of both.
>=20
> Recently had to fix some legacy code where the result of `filemtime` w=
as being passed to `gmdate` to format
> the modification timestamp. `filemtime` returns false on failure, but =
this is silently coerced to zero
> (a valid timestamp) when passed to the int parameter, which would resu=
lt in the script continuing with bad
> data instead of halting with a type error.
>=20
> Cast-to-bool can cause the same kinds of issues, which are sometimes e=
ven harder to notice. Consider the following:
>=20
>     function processArray(array $items, bool $hasCertainKey) { ... }
>=20
>     $keyOrFalse =3D array_search('my value', $items);
>=20
>     processArray($items, $keyOrFalse);
>=20
> It's very easy to miss the bug in this code, especially since it seems=
 to function correctly as long as 'my value'
> is not in the array, or is not the first item in the array. However, w=
hen it's at index 0 the key will be silently
> coerced to false and the array will be incorrectly processed as though=
 the value is not in the array.
>=20
> I believe deprecating type juggling to/from bool will help avoid creat=
ing bugs like this (and likely
> surface existing ones that should be fixed).
>=20
> Kind regards,
> Theodore

I'm not so confident that will be the case. In lots of strict-mode code =
I've worked with over the years, people tend to blindly cast things with=
out realizing they're in a worse situation than using non-strict mode. L=
ike `((int)"123password") =3D=3D=3D 123`, however attempting to coerce t=
hat string to an int results in a proper type error in non-strict mode.

That is to say, I highly suspect that `gmdate(filemtime($file))` would j=
ust be rewritten as `gmdate((int)filemtime($file))` without a second tho=
ught.

In your other example showing the difference in array_search, I also hig=
hly suspect people would just cast it to bool without noticing the 0-key=
 edge case.

Both cases, I believe, can simply be solved by tooling highlighting when=
 you're passing a union type to a function that doesn't overlap with the=
 function's expectations. ("you are passing int|string to a function exp=
ecting bool" and/or "you are casting int|string to bool, check that (boo=
l)"0" won't be an edge-case; consider using empty() instead").

=E2=80=94 Rob
--d3cff7b818324346abf24501efc4bda5
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Sat, Jul 12, 2025, at 01:29, Theodore Brown wrote:<=
/div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On Fri, July 11=
, 2025 at 05:00 G. P. Banyard wrote:</div><div><br></div><div>&gt;&gt; O=
n Monday, 30 June 2025 at 10:26, Nicolas Grekas wrote:&nbsp;&nbsp;</div>=
<div>&gt;&gt; ...&nbsp;&nbsp;</div><div>&gt;&gt; The latter, cast-from-b=
ool, I think they're all useful improvements. While most likely harmless=
 in all the specific</div><div>&gt;&gt; cases of the PR, doing e.g. an s=
trpos() on false feels hardly legit. I'm therefore sympathetic to making=
 these changes.</div><div>&gt;&gt;</div><div>&gt;&gt; For cast-to-bool, =
I'm WAY less convinced. From the PR above, explicit casts like "return (=
bool) preg_match(...)"</div><div>&gt;&gt; on a method that returns a "bo=
ol" or "(bool) ($this-&gt;loggedErrors &amp; $type)" are a clear downgra=
de: it makes the</div><div>&gt;&gt; typing PHP just more verbose without=
 any real benefit. That doesn't look worth asking the whole ecosystem to=
 fix</div><div>&gt;&gt; those deprecations. It is especially hard to see=
 this as an improvement when comparing to using the same</div><div>&gt;&=
gt; expressions with e.g. the "if ()" operator, which doesn't need the e=
xplicit cast (and shouldn't of course).</div><div><br></div><div>From my=
 experience there is a very real benefit to deprecating both cast-from-b=
ool and cast-to-bool.</div><div>Let me give an example of both.</div><di=
v><br></div><div>Recently had to fix some legacy code where the result o=
f `filemtime` was being passed to `gmdate` to format</div><div>the modif=
ication timestamp. `filemtime` returns false on failure, but this is sil=
ently coerced to zero</div><div>(a valid timestamp) when passed to the i=
nt parameter, which would result in the script continuing with bad</div>=
<div>data instead of halting with a type error.</div><div><br></div><div=
>Cast-to-bool can cause the same kinds of issues, which are sometimes ev=
en harder to notice. Consider the following:</div><div><br></div><div>&n=
bsp;&nbsp;&nbsp; function processArray(array $items, bool $hasCertainKey=
) { ... }</div><div><br></div><div>&nbsp;&nbsp;&nbsp; $keyOrFalse =3D ar=
ray_search('my value', $items);</div><div><br></div><div>&nbsp;&nbsp;&nb=
sp; processArray($items, $keyOrFalse);</div><div><br></div><div>It's ver=
y easy to miss the bug in this code, especially since it seems to functi=
on correctly as long as 'my value'</div><div>is not in the array, or is =
not the first item in the array. However, when it's at index 0 the key w=
ill be silently</div><div>coerced to false and the array will be incorre=
ctly processed as though the value is not in the array.</div><div><br></=
div><div>I believe deprecating type juggling to/from bool will help avoi=
d creating bugs like this (and likely</div><div>surface existing ones th=
at should be fixed).</div><div><br></div><div>Kind regards,</div><div>Th=
eodore</div></blockquote><div><br></div><div>I'm not so confident that w=
ill be the case. In lots of strict-mode code I've worked with over the y=
ears, people tend to blindly cast things without realizing they're in a =
worse situation than using non-strict mode. Like `((int)"123password") =3D=
=3D=3D 123`, however attempting to coerce that string to an int results =
in a proper type error in non-strict mode.</div><div><br></div><div>That=
 is to say, I highly suspect that `gmdate(filemtime($file))` would just =
be rewritten as `gmdate((int)filemtime($file))` without a second thought=
.</div><div><br></div><div>In your other example showing the difference =
in array_search, I also highly suspect people would just cast it to bool=
 without noticing the 0-key edge case.</div><div><br></div><div>Both cas=
es, I believe, can simply be solved by tooling highlighting when you're =
passing a union type to a function that doesn't overlap with the functio=
n's expectations. ("you are passing int|string to a function expecting b=
ool" and/or "you are casting int|string to bool, check that (bool)"0" wo=
n't be an edge-case; consider using empty() instead").<br></div><div><br=
></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--d3cff7b818324346abf24501efc4bda5--