Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117739
Content-Type: multipart/alternative;
 boundary="------------mQCEsU8x0GF2fUnavE58Xw23"
Message-ID: <a09a6118-f6ac-2804-b9d0-9a9bcda0a219@gmx.net>
Date: Tue, 17 May 2022 12:22:21 +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: internals@lists.php.net
References: <eb2bef11-4027-8555-93e3-89c2cc4f5a18@gmx.net>
 <b9f52679-8ef8-2f0d-0805-4c273cc4515f@seld.be>
In-Reply-To: <b9f52679-8ef8-2f0d-0805-4c273cc4515f@seld.be>
Subject: Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions
From: a.leathley@gmx.net (Andreas Leathley)

--------------mQCEsU8x0GF2fUnavE58Xw23
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 17.05.22 11:18, Jordi Boggiano wrote:
>
> Thanks for the RFC. I think it's overall a good idea, especially for
> cases like "false" =3D> true, and arguably for ints >1/<0, but my gut
> feeling is the string=3D>bool deprecation will lead to a lot of pain.
>
> I definitely see this being done in many places where you expect any
> string value to be true and an empty string to be false (without
> consideration for the "false" case which is more common in config
> style use cases).
>
> I don't know what you could do to improve this without making the RFC
> useless though. I wish these things could be tried out in alpha or
> even up to early RC builds so we could hopefully get community
> feedback in before deciding whether it's worth the pain inflicted or not=
.

For what its worth, I already found some bugs in the php-src tests where
a function definition was probably changed at some point and a string
was passed to a bool argument which was obviously not intended, or where
a weird value was used for a boolean argument without any apparent
reason. These are the type of unintended coercions I am trying to bring
to light with the RFC.

Using any string as true is also already a bit dangerous: "0" is a
special case string that results to false, which adds a big wrinkle to
the assumption "non-empty string is true".

My main arguments why I think this will not lead to too much unnecessary
pain:

  * Each individual case is easy to fix, the easiest (but also least
    useful) would be to loosly compare a value to true ($value =3D=3D true=
)
    instead of directly giving the value to a typed bool
  * bool arguments for internal functions are usually optional, less
    numerous and are much more likely to be set by a constant expression
    than a variable
  * deprecation notices are easy to ignore, and the "disadvantage" of
    the high number of deprecation notices with 8.0 and 8.1 should be
    that most tooling and codebases have gotten more used to dealing
    with them without too much panic

I also added these points to the RFC, because I think there is some
resentment built up for deprecation notices by now, which I can understand=
.

--------------mQCEsU8x0GF2fUnavE58Xw23--