Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117608
Content-Type: multipart/alternative;
 boundary="------------cmdbNOdx3D7si2O2CLR2Rrt5"
Message-ID: <3fcdfa2c-7a9c-d634-ea56-8b1e5bf1a911@gmx.net>
Date: Tue, 26 Apr 2022 11:54:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Content-Language: en-US
To: PHP Developers Mailing List <internals@lists.php.net>
Subject: Stricter implicit boolean coercions
From: a.leathley@gmx.net (Andreas Leathley)

--------------cmdbNOdx3D7si2O2CLR2Rrt5
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hello Internals,

Implicit type coercions (when not using strict_types) have become
increasingly less lossy/surprising in PHP, especially coercions to
integer and float, where you get a TypeError if you pass a non-numeric
string to an integer parameter, and a deprecation notice if you pass a
float(-string) with a fractional part to an integer parameter. The big
exception so far is coercions to boolean, where you can provide any
scalar value and never get an error or a notice.

Any non-empty string (except "0") is converted to true and any non-zero
integer or float is converted to true. From my perspective this can
easily lead to hidden bugs, for example when passing the wrong variable
to a boolean argument or boolean property. Passing a string like "hello"
as a boolean is probably a bug, just like passing the number 854 or the
float 0.1 . "on" and "off" and "true" and "false" all lead to a boolean
true, as examples of strings that could be used in applications and
might not all be meant as a value of true.

I have not found any past proposals or discussions to change boolean
coercions, so I would like to find out how the thoughts on internals are
to change this, or if there are any reasons not to change this that I
have not thought of. Only allowing the following values would make sense
from my perspective:

'1' =3D> true
1 =3D> true
1.0 =3D> true
'' =3D> false
'0' =3D> false
0 =3D> false
0.0 =3D> false

I can also see a case for allowing the strings 'true' and 'false', and
changing 'false' to be coerced to false, but that would be a BC break. I
am not sure if that is worthwhile.

Anything else would emit either a notice or a warning as a first step
(to be determined). My main goal would be to make these
probably-not-boolean usages more visible in codebases. Depending on the
feedback here I would create an RFC and try to do an implementation (to
then discuss it in more detail), so as of now this is mostly about
getting some basic feedback on such a change, and if someone else has
had any similar thoughts/plans.

Thanks for any feedback!

Andreas Leathley

--------------cmdbNOdx3D7si2O2CLR2Rrt5--