Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117614
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Date: Tue, 26 Apr 2022 14:47:49 +0200
References: <3fcdfa2c-7a9c-d634-ea56-8b1e5bf1a911@gmx.net>
To: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <3fcdfa2c-7a9c-d634-ea56-8b1e5bf1a911@gmx.net>
Message-ID: <C7ADCE20-81E1-4F7C-B0B7-1D32173A3E5B@cschneid.com>
Subject: Re: [PHP-DEV] Stricter implicit boolean coercions
From: cschneid@cschneid.com (Christian Schneider)

Am 26.04.2022 um 11:54 schrieb Andreas Leathley <a.leathley@gmx.net>:
> 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.

There are two big reasons:
- BC: Checking for the truthiness of a value is very common and would =
require a lot of code changes.
- Some of us like the conciseness of "if ($foo) ...", see below

> 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.

I'm definitely against adding more special cases like 'false'.
Side-note: Removing something like '0' =3D> false is also a BC break, =
not just adding 'false'.

> 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.


One of the big issues I have with this (as well as undefined variables =
not being allowed in if ($foo)) is that the replacement constructs are =
clunky:
	if ($foo)  =3D>. if (!empty($foo))

For me this is quite a regression in readability but then again that's a =
matter of taste.
And would !empty($foo) even work in your world or how would empty() be =
defined?

Regards,
- Chris