Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117778
Message-ID: <584ac903-4742-0d78-5eed-a795c6b70adb@gmx.net>
Date: Tue, 24 May 2022 00:25:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Content-Language: en-US
To: internals@lists.php.net
References: <eb2bef11-4027-8555-93e3-89c2cc4f5a18@gmx.net>
 <CAFPFaMLS3VsDUL6=9-6GgiXoDgQ4WC_gSHfUP_y6EEKwPRHvOw@mail.gmail.com>
In-Reply-To: <CAFPFaMLS3VsDUL6=9-6GgiXoDgQ4WC_gSHfUP_y6EEKwPRHvOw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions
From: a.leathley@gmx.net (Andreas Leathley)

On 23.05.22 22:54, G. P. B. wrote:
> I don't like this RFC as it introduces special coercion semantics for
> boolean *only* in a function (+ typed properties (well at least I hope i=
t
> impacts typed properties)) context.
>
> The obvious other context is the logical one with conditional statements
> and/or boolean operators (&&, ||, etc.) where it is pretty typical to do=
 if
> ($string) {} and use $string as a boolean value.
> Having this be true in some contexts and false in others, depending on t=
he
> content of the string is far from ideal.
> However, implicit coercion to bool can also arise when doing comparisons
> where one of the operands is null or bool.
> In this case which semantics should be used?

The problem is that coercion to a typed boolean is not the same as
checking an expression for truthiness. It is somewhat related, but when
there is a coercion to a typed boolean only scalar values can be
coerced, which makes a big difference. Something like

if ([''])

is basically the same as

if ([''] =3D=3D true)

which is why I call it checking for truthiness. Yet

$obj->booleanProperty =3D [''];

will lead to a type error. So there is a clear difference there already.
I also think the expectation is a different one - something like

if ($string)

is, as far as I have seen, most often used to check if a string it not
empty. Yet if you do

$obj->booleanProperty =3D $string;

you then seem to specifically want to end up with a boolean type, not do
a fuzzy check for truthiness. To me that is a very different situation
where I actually find the current behavior surprising, in that is does
not matter at all what scalar value I give a typed boolean, it will be
happy with anything, and if it was a long string that was converted to
boolean, you do possibly lose information. That can easily happen if
someone changes a property from a string to boolean, but still assigns
it a string somewhere.

As soon as you use operators like && or || the intention becomes clearer
again:

$obj->booleanProperty =3D $string && $string2;

There you are not passing the string directly to a boolean property, you
are checking an expression, and you can even do

$obj->booleanProperty =3D $array && $array2; // cannot pass an array to a
boolean, but you can check an array (or two) for truthiness / not being
empty

> Can this prevent bugs, for sure, but within the function context we alre=
ady
> have a tool to deal with these sorts of issues with strict_types.

But could you not argue the same for integers too? Why when you pass a
string to an int parameter does it check if it is numeric, and not
auto-coerce "hello" to 0? That is different behavior too, and one can
use strict_types or explicit coercions instead. My argument is not that
the proposal in this RFC is somewhat elegant or solves deep-rooted
issues in the language. Similar to the numeric checks for int parameters
I am interested in this for purely practical reasons. If somewhere in
your application the integer -376 is passed to a boolean property (and
coerced to true), would you not rather know about it? Is it not likely a
bug, or at least an oversight? Would it not be easier on developers to
know that only 7 scalar values are considered "unambigous" when passing
to a typed boolean, and that they would be informed if they pass
something else?

I already rewrote the passage about raising this to a TypeError, where I
state that this should be determined later when there is sufficient
experience with these deprecation notices, and for me that is not really
urgent - if this just remains an unintrusive deprecation notice for the
next 10 years that would be fine with me. But I am convinced this will
be a useful notice in many applications, where bugs can be found that
otherwise would have stayed hidden for a very long time.

I appreciate your feedback, and if I can improve anything about the RFC
I am open to ideas. I think your RFCs for the type system have made PHP
a much better language, and you seem to think about the big picture of
the types in PHP, which is important for the language. This RFC might
seem like a niche specific change and it does not affect much of PHP
itself, but to me that could be what makes it a useful addition - if it
mainly reveals bugs in applications, couldn't that be enough of a reason
in favor of it?