Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127543
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 02 Jun 2025 23:02:06 +0200
To: internals@lists.php.net
Message-ID: <bd799977-b27e-437f-8599-0b36c1366f15@app.fastmail.com>
In-Reply-To: 
 <3Yl0UGauXmKqk7s7Hqbv6iaXru-hZHf8Wj6VjwwihgRSaqZo5EZ2ndsOle-ae41C-lvnirynWt6PpuD7UJPL0zPCw18QHFE81Eb--fiiEbc=@gpb.moe>
References: 
 <3Yl0UGauXmKqk7s7Hqbv6iaXru-hZHf8Wj6VjwwihgRSaqZo5EZ2ndsOle-ae41C-lvnirynWt6PpuD7UJPL0zPCw18QHFE81Eb--fiiEbc=@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=3738bb6916ca413995d107f501be6a56
From: rob@bottled.codes ("Rob Landers")

--3738bb6916ca413995d107f501be6a56
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Mon, Jun 2, 2025, at 18:11, Gina P. Banyard wrote:
> Hello internals,
>=20
> This is the first RFC out of a set of type system related RFCs I want =
to propose for PHP 8.5.
> It also used the recently enabled Markdown support on the wiki, so the=
re might be a few oddities.
>=20
> The RFC proposes to deprecate implicit type coercions to and from the =
bool type for other scalar types.
> This a "weak" mode change only, as when strict_types are enabled none =
of these coercions can happen.
>=20
> Let me know what you think about it.
>=20
> RFC: https://wiki.php.net/rfc/deprecate-function-bool-type-juggling
>=20
> Best regards,
>=20
> Gina P. Banyard
>=20

No offense, but this feels like it was written by someone who doesn=E2=80=
=99t use non-strict mode very often. The rules around coercion are prett=
y simple and well documented. Further, this makes a ton of shorthand nea=
rly impossible =E2=80=94 the manual casting to bool in strict mode is on=
e of the most annoying casts someone has to do (and people screw up orde=
r of operations all the time leading to subtle bugs worse than coercion)=
. Bringing this into all of php is probably not a good idea.=20

> Type juggling of strings to bool is similarly error-prone. The strings=
 "" and "0" are converted to false, but "false", " ", and other strings =
which an (int) cast converts to 0 are coerced to true.

If I understand correctly, you are saying it is weird why the bytes 66 6=
1 6C 73 65 are =E2=80=9Ctrue=E2=80=9D and 30 is a special case, but not =
20? If I remember my history correctly, 30 is special-cased because form=
s used to send =E2=80=9C0=E2=80=9D on checkboxes (if it sent it at all; =
it changed from decade to decade).

I don=E2=80=99t see the benefit of removing this implicit coercion.

=E2=80=94 Rob
--3738bb6916ca413995d107f501be6a56
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 Mon, Jun 2, 2025, at 18:11, Gina P. Banyard wrote:<=
/div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hello internals=
,</div><div><br></div><div>This is the first RFC out of a set of type sy=
stem related RFCs I want to propose for PHP 8.5.</div><div>It also used =
the recently enabled Markdown support on the wiki, so there might be a f=
ew oddities.</div><div><br></div><div>The RFC proposes to deprecate impl=
icit type coercions to and from the bool type for other scalar types.</d=
iv><div>This a "weak" mode change only, as when strict_types are enabled=
 none of these coercions can happen.</div><div><br></div><div>Let me kno=
w what you think about it.</div><div><br></div><div>RFC:&nbsp;<a href=3D=
"https://wiki.php.net/rfc/deprecate-function-bool-type-juggling">https:/=
/wiki.php.net/rfc/deprecate-function-bool-type-juggling</a></div><div><b=
r></div><div>Best regards,</div><div><br></div><div>Gina P. Banyard</div=
><div><br></div></blockquote><div><br></div><div>No offense, but this fe=
els like it was written by someone who doesn=E2=80=99t use non-strict mo=
de very often. The rules around coercion are pretty simple and well docu=
mented. 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><div><br></div><blockquo=
te type=3D"cite"><div>Type juggling of strings to bool is similarly erro=
r-prone. The strings "" and "0" are converted to false, but "false", " "=
, and other strings which an (int) cast converts to 0 are coerced to tru=
e.</div></blockquote><div><br></div><div>If I understand correctly, you =
are saying it is weird why the bytes&nbsp;66 61 6C 73 65 are =E2=80=9Ctr=
ue=E2=80=9D and&nbsp;30 is a special case, but not&nbsp;20? If I remembe=
r my history correctly, 30 is special-cased because forms used to send =E2=
=80=9C0=E2=80=9D on checkboxes (if it sent it at all; it changed from de=
cade to decade).</div><div><br></div><div>I don=E2=80=99t see the benefi=
t of removing this implicit coercion.</div><div><br></div><div id=3D"sig=
121229152">=E2=80=94 Rob</div></body></html>
--3738bb6916ca413995d107f501be6a56--