Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117774
To: internals@lists.php.net
References: <eb2bef11-4027-8555-93e3-89c2cc4f5a18@gmx.net>
Message-ID: <628BD938.1010409@adviesenzo.nl>
Date: Mon, 23 May 2022 20:58:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <eb2bef11-4027-8555-93e3-89c2cc4f5a18@gmx.net>
Content-Type: multipart/alternative;
 boundary="------------060901060205070509010609"
Subject: Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

--------------060901060205070509010609
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 16-5-2022 17:06, Andreas Leathley wrote:
> Hello Internals,
>
> After the first discussion about this topic
> (https://externals.io/message/117608) I have created a preliminary
> implementation and an RFC for making implicit boolean type coercions
> more strict:
>
> https://wiki.php.net/rfc/stricter_implicit_boolean_coercions
>
> With this email I'm starting the two week discussion period. I welcome
> any feedback on it and hope to further iron out the implementation if
> needed. I mainly chose the route of introducing a deprecation notice
> because it is in line with other RFCs that have similar goals (like the
> Deprecate implicit non-integer-compatible float to int conversions RFC),
> and it is fairly non-intrusive.

This RFC worries me as, in my opinion, it makes PHP's behaviour more 
surprising and inconsistent, not less.

It also raises the cognitive complexity for developers by yet another level.

1. It introduces a new interpretation of boolean type coercion, which is 
only applied against type declarations.
2. This new interpretation is not consistent with "normal" boolean type 
coercion, not consistent with strict types (no coercion) and also not 
consistent with what is considered a valid boolean value by the Filter 
extension.

While I agree that the current behaviour of PHP can hide bugs, I fear 
that even more bugs will be introduced when PHP contains yet a third 
form of coercion to boolean and the type coercion used is dependent on 
the context.

I see enough bugs on a daily basis which are/were introduced because 
people don't know the type coercion rules well enough. Adding yet 
another contextual layer to type coercion, makes things MORE complex, 
not less.

I fear this will only lead to more bugs, not less (because people new to 
PHP will learn the "type declaration" based boolean coercion rules and 
assume they apply everywhere).

I also fear that for code bases which do not (yet) use scalar type 
declarations, this will be one more argument not to introduce scalar 
type declarations (while they should).

I'd say that for this RFC to be acceptable it would need to apply to all 
implicit type coercions to boolean. However, the BC-break that would 
cause and the fall-out of this for non-greenfields codebases is just too 
huge, which, to me, makes this RFC a very strong no-no.

All in all, I largely agree with the flaws in this proposal as 
previously pointed out by Christian Schneider in the preliminary 
discussion. And I don't see those concerns addressed in the RFC (other 
than making it more explicit what the actual intended change is).

Smile,
Juliette

--------------060901060205070509010609--