Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127569
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 03 Jun 2025 19:39:21 +0200
To: "Gina P. Banyard" <internals@gpb.moe>
Cc: internals@lists.php.net
Message-ID: <b8cb785b-d678-428a-966b-96458739ad07@app.fastmail.com>
In-Reply-To: 
 <txQRn-ii_fBEImIkaQ_IWEKN0eq_Hh2S-lkGsQeKnWCcXuDmReMLAiZM7sgKOUKp4IETIhqV3UIhSPM_hHizjXKwPcVKblJ2umd7Z8jf2Hs=@gpb.moe>
References: 
 <3Yl0UGauXmKqk7s7Hqbv6iaXru-hZHf8Wj6VjwwihgRSaqZo5EZ2ndsOle-ae41C-lvnirynWt6PpuD7UJPL0zPCw18QHFE81Eb--fiiEbc=@gpb.moe>
 <bd799977-b27e-437f-8599-0b36c1366f15@app.fastmail.com>
 <txQRn-ii_fBEImIkaQ_IWEKN0eq_Hh2S-lkGsQeKnWCcXuDmReMLAiZM7sgKOUKp4IETIhqV3UIhSPM_hHizjXKwPcVKblJ2umd7Z8jf2Hs=@gpb.moe>
Subject: Re: [PHP-DEV][RFC] Deprecate type juggling to and from bool type within the
 function type juggling context
Content-Type: multipart/alternative;
 boundary=9491128bafb84b1a9140db855e5403b1
From: rob@bottled.codes ("Rob Landers")

--9491128bafb84b1a9140db855e5403b1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Tue, Jun 3, 2025, at 18:19, Gina P. Banyard wrote:
> On Monday, 2 June 2025 at 22:05, Rob Landers <rob@bottled.codes> wrote:
>> No offense, but this feels like it was written by someone who doesn=E2=
=80=99t use non-strict mode very often.
>=20
> As yes, saying this to me, someone that is known to have said on stage=
, multiple times, during talks that
> > The strict_types declare was a mistake.
> Something I even reiterated 7 weeks ago at a Drupal conference. [1]
> It would be nice that you don't make assumption about how I write PHP =
code, as I use weak and strict mode extensively while being annoyed with=
 both modes constantly.
> Moreover, even if one uses strict mode one must still know how weak mo=
de behaves as closures/callables do not follow the typing mode in which =
they have been declared.

Hey Gina,

As mentioned, my intent wasn=E2=80=99t to offend. My goal was to tell yo=
u how it read, from my perspective, whether you intended it to or not. A=
s in someone trying to force everyone using weak mode to use strict mode=
. I=E2=80=99m really sorry that it came across that way, though.

>=20
>> The rules around coercion are pretty simple and well documented.
>=20
> Considering I have given *multiple* talks about PHP's type system and =
type coercions rules, many people do *not* find them simple or intuitive=
 and get bitten by them constantly.

That is a fair point. I=E2=80=99ve seen the same confusion among juniors=
 (and sometimes seniors!) over the years. My sense, though, is that some=
 confusion is less about PHP=E2=80=99s type system itself and more about=
 the unique way PHP handles requests compared to other languages. In mos=
t languages, frameworks insulate you from the raw request data and make =
explicit choices about parsing and typing. In PHP, by contrast, you ofte=
n get the raw bytes, and it is up to you (or your framework, hopefully) =
to massage that into proper types=E2=80=94which can lead to surprising b=
ehaviours if you=E2=80=99re not careful.

I think sometimes people bring expectations from other ecosystems (where=
, say, the string =E2=80=9Cfalse=E2=80=9D might have special meaning) an=
d are surprised when PHP treats =E2=80=9Cfalse=E2=80=9D like any other n=
on-empty string. Maybe that mismatch is the root of a lot of frustration=
s?

Curious if you see it the same way, or if there is something more fundam=
ental in PHP=E2=80=99s type rules you think causes the confusion?

>=20
>> Further, this makes a ton of shorthand nearly impossible =E2=80=94 th=
e manual casting to bool in strict mode is one of the most annoying cast=
s someone has to do (and people screw up order of operations all the tim=
e leading to subtle bugs worse than coercion). Bringing this into all of=
 php is probably not a good idea.=20
>=20
> It would have been nice to showcase some of these shorthands rather th=
an hiding them behind some sort of mystic as a counterargument.
> I really would like to know in which cases you use non-boolean values =
as argument to boolean parameters.
> People creating more subtle and worse bugs due to arbitrary casting is=
 precisely why I want to unify the typing modes, so it's good to know th=
at we think somewhat the same.

// From a real codebase (sanitized):
$shouldStop =3D (bool)($result =3D $service->doSomething($input)) && $re=
sult->isError();

This pattern comes up a lot in strict mode: you have to be extra careful=
 with casts and parentheses, or you can end up with subtle bugs like acc=
identally always returning true/false, or masking null/error values. In =
looser modes, this just =E2=80=9Cworked=E2=80=9D, but strictness can mak=
e it surprisingly easy to trip up.

In my experience, a lot of =E2=80=9Cnon-boolean to boolean=E2=80=9D case=
s are legacy patterns or integrations, but sometimes we=E2=80=99re deali=
ng with values that can be =E2=80=9Cfalsy=E2=80=9D in multiple ways (emp=
ty array, 0, '', etc.). Sometimes we=E2=80=99re adapting legacy code or =
writing wrappers that need to accept a wide range of inputs.

The problem, in my view, is that *forcing* strictness everywhere makes t=
he simple, idiomatic code that worked in PHP for years much more verbose=
; and potentially more error-prone if the developer isn=E2=80=99t carefu=
l with casts or operator precedence.

>=20
>>> Type juggling of strings to bool is similarly error-prone. The strin=
gs "" and "0" are converted to false, but "false", " ", and other string=
s which an (int) cast converts to 0 are coerced to true.
>>=20
>> If I understand correctly, you are saying it is weird why the bytes 6=
6 61 6C 73 65 are =E2=80=9Ctrue=E2=80=9D and 30 is a special case, but n=
ot 20? If I remember my history correctly, 30 is special-cased because f=
orms used to send =E2=80=9C0=E2=80=9D on checkboxes (if it sent it at al=
l; it changed from decade to decade).
>=20
> I know the reason why we coerce the string "0" to false.
> But it is very atypical compared to every other programming language, =
so yes it is "weird".

I will 100% agree with you about "0" being *false*. It was a handy short=
cut 20 years ago, but these days it creates more confusion than it solve=
s.

>=20
>> I don=E2=80=99t see the benefit of removing this implicit coercion.
>=20
> The statement is noted.
>=20
>=20
> Regards,
>=20
> Gina P. Banyard
>=20
> [1] https://youtu.be/85fgBcV3BuM?t=3D2832

=E2=80=94 Rob
--9491128bafb84b1a9140db855e5403b1
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 Tue, Jun 3, 2025, at 18:19, Gina P. Banyard wrote:<=
/div><blockquote type=3D"cite" id=3D"qt" style=3D""><div style=3D"font-f=
amily:Arial, sans-serif;font-size:14px;"><div class=3D"qt-protonmail_quo=
te"><div>On Monday, 2 June 2025 at 22:05, Rob Landers &lt;rob@bottled.co=
des&gt; wrote:</div><blockquote class=3D"qt-protonmail_quote" type=3D"ci=
te"><div>No offense, but this feels like it was written by someone who d=
oesn=E2=80=99t use non-strict mode very often.</div></blockquote><div><b=
r></div><div>As yes, saying this to me, someone that is known to have sa=
id on stage, multiple times, during talks that</div><div>&gt; <span>The =
strict_types declare was a mistake.</span></div><div>Something I even re=
iterated 7 weeks ago at a Drupal conference. [1]</div><div>It would be n=
ice that you don't make assumption about how I write PHP code, as I use =
weak and strict mode extensively while being annoyed with both modes con=
stantly.</div><div>Moreover, even if one uses strict mode one must still=
 know how weak mode behaves as closures/callables do not follow the typi=
ng mode in which they have been declared.</div></div></div></blockquote>=
<div><br></div><div>Hey Gina,</div><div><br></div><div>As mentioned, my =
intent wasn=E2=80=99t to offend. My goal was to tell you how it read, fr=
om my perspective, whether you intended it to or not. As in someone tryi=
ng to force everyone using weak mode to use strict mode. I=E2=80=99m rea=
lly sorry that it came across that way, though.</div><div><br></div><blo=
ckquote type=3D"cite" id=3D"qt" style=3D""><div style=3D"font-family:Ari=
al, sans-serif;font-size:14px;"><div class=3D"qt-protonmail_quote"><div>=
<br></div><blockquote class=3D"qt-protonmail_quote" type=3D"cite"><div>T=
he rules around coercion are pretty simple and well documented.</div></b=
lockquote><div><br></div><div>Considering I have given *multiple* talks =
about PHP's type system and type coercions rules, many people do *not* f=
ind them simple or intuitive and get bitten by them constantly.</div></d=
iv></div></blockquote><div><br></div><div>That is a fair point. I=E2=80=99=
ve seen the same confusion among juniors (and sometimes seniors!) over t=
he years. My sense, though, is that some confusion is less about PHP=E2=80=
=99s type system itself and more about the unique way PHP handles reques=
ts compared to other languages. In most languages, frameworks insulate y=
ou from the raw request data and make explicit choices about parsing and=
 typing. In PHP, by contrast, you often get the raw bytes, and it is up =
to you (or your framework, hopefully) to massage that into proper types=E2=
=80=94which can lead to surprising behaviours if you=E2=80=99re not care=
ful.</div><div><br></div><div>I think sometimes people bring expectation=
s from other ecosystems (where, say, the string =E2=80=9Cfalse=E2=80=9D =
might have special meaning) and are surprised when PHP treats =E2=80=9Cf=
alse=E2=80=9D like any other non-empty string. Maybe that mismatch is th=
e root of a lot of frustrations?</div><div><br></div><div>Curious if you=
 see it the same way, or if there is something more fundamental in PHP=E2=
=80=99s type rules you think causes the confusion?<br></div><div><br></d=
iv><blockquote type=3D"cite" id=3D"qt" style=3D""><div style=3D"font-fam=
ily:Arial, sans-serif;font-size:14px;"><div class=3D"qt-protonmail_quote=
"><div><br></div><blockquote class=3D"qt-protonmail_quote" type=3D"cite"=
><div>Further, this makes a ton of shorthand nearly impossible =E2=80=94=
 the manual casting to bool in strict mode is one of the most annoying c=
asts someone has to do (and people screw up order of operations all the =
time leading to subtle bugs worse than coercion). Bringing this into all=
 of php is probably not a good idea.&nbsp;</div></blockquote><div><br></=
div><div>It would have been nice to showcase some of these shorthands ra=
ther than hiding them behind some sort of mystic as a counterargument.</=
div><div>I really would like to know in which cases you use non-boolean =
values as argument to boolean parameters.</div><div>People creating more=
 subtle and worse bugs due to arbitrary casting is precisely why I want =
to unify the typing modes, so it's good to know that we think somewhat t=
he same.</div></div></div></blockquote><div><br></div><div>// From a rea=
l codebase (sanitized):</div><div>$shouldStop =3D (bool)($result =3D $se=
rvice-&gt;doSomething($input)) &amp;&amp; $result-&gt;isError();</div><d=
iv><br></div><div>This pattern comes up a lot in strict mode: you have t=
o be extra careful with casts and parentheses, or you can end up with su=
btle bugs like accidentally always returning true/false, or masking null=
/error values. In looser modes, this just =E2=80=9Cworked=E2=80=9D, but =
strictness can make it surprisingly easy to trip up.</div><div><br></div=
><div>In my experience, a lot of =E2=80=9Cnon-boolean to boolean=E2=80=9D=
 cases are legacy patterns or integrations, but sometimes we=E2=80=99re =
dealing with values that can be =E2=80=9Cfalsy=E2=80=9D in multiple ways=
 (empty array, 0, '', etc.). Sometimes we=E2=80=99re adapting legacy cod=
e or writing wrappers that need to accept a wide range of inputs.</div><=
div><br></div><div>The problem, in my view, is that <i>forcing</i> stric=
tness everywhere makes the simple, idiomatic code that worked in PHP for=
 years much more verbose; and potentially more error-prone if the develo=
per isn=E2=80=99t careful with casts or operator precedence.<br></div><d=
iv><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div style=3D=
"font-family:Arial, sans-serif;font-size:14px;"><div class=3D"qt-protonm=
ail_quote"><div><br></div><blockquote class=3D"qt-protonmail_quote" type=
=3D"cite"><blockquote type=3D"cite"><div>Type juggling of strings to boo=
l is similarly error-prone. The strings "" and "0" are converted to fals=
e, but "false", " ", and other strings which an (int) cast converts to 0=
 are coerced to true.</div></blockquote><div><br></div><div>If I underst=
and correctly, you are saying it is weird why the bytes&nbsp;66 61 6C 73=
 65 are =E2=80=9Ctrue=E2=80=9D and&nbsp;30 is a special case, but not&nb=
sp;20? If I remember my history correctly, 30 is special-cased because f=
orms used to send =E2=80=9C0=E2=80=9D on checkboxes (if it sent it at al=
l; it changed from decade to decade).</div></blockquote><div><br></div><=
div>I know the reason why we coerce the string "0" to false.</div><div>B=
ut it is very atypical compared to every other programming language, so =
yes it is "weird".</div></div></div></blockquote><div><br></div><div>I w=
ill 100% agree with you about "0" being <b>false</b>. It was a handy sho=
rtcut 20 years ago, but these days it creates more confusion than it sol=
ves.</div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D"">=
<div style=3D"font-family:Arial, sans-serif;font-size:14px;"><div class=3D=
"qt-protonmail_quote"><div><br></div><blockquote class=3D"qt-protonmail_=
quote" type=3D"cite"><div>I don=E2=80=99t see the benefit of removing th=
is implicit coercion.</div></blockquote><div><br></div><div>The statemen=
t is noted.</div><div><span></span><br></div><div><br></div><div><span>R=
egards,</span></div><div><br></div><div><span>Gina P. Banyard</span></di=
v></div><div class=3D"qt-protonmail_quote"><span></span><br></div><div c=
lass=3D"qt-protonmail_quote"><span>[1]&nbsp;<span><a target=3D"_blank" r=
el=3D"noreferrer nofollow noopener" href=3D"https://youtu.be/85fgBcV3BuM=
?t=3D2832">https://youtu.be/85fgBcV3BuM?t=3D2832</a></span></span></div>=
</div></blockquote><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob=
</div></body></html>
--9491128bafb84b1a9140db855e5403b1--