Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117775
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
In-Reply-To: <628BD938.1010409@adviesenzo.nl>
Date: Mon, 23 May 2022 20:38:26 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <C9BCC520-B586-4B96-B4C2-AF5251967C2A@craigfrancis.co.uk>
References: <eb2bef11-4027-8555-93e3-89c2cc4f5a18@gmx.net>
 <628BD938.1010409@adviesenzo.nl>
To: Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>
Subject: Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions
From: craig@craigfrancis.co.uk (Craig Francis)

On 23 May 2022, at 19:58, Juliette Reinders Folmer =
<php-internals_nospam@adviesenzo.nl> wrote:
> 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).
>=20
> 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.


Forgive my ignorance, but when scalar types were introduced, I initially =
assumed type coercion would use the same rules as `strval($var)`, =
`(string) $val`, `'a' . $val`, `intval($val)`, etc. I now appreciate =
that isn't the case, but I never understood why the following functions =
were not equivalent:

```
function my_function1($s, $i, $f, $b) {
  $s =3D strval($s);
  $i =3D intval($i);
  $f =3D floatval($f);
  $b =3D boolval($b);
  var_dump($s, $i, $f, $b);
}

function my_function2(string $s, int $i, float $f, bool $b) {
  var_dump($s, $i, $f, $b);
}
```

Where the second function, using scalar type declarations, has the =
advantage of being much shorter, and clearer for Static Analysis, IDE's, =
documentation, etc... if only it was as easy to add to existing =
projects.

This isn't to say `boolval()` and other ways of changing type to a =
boolean couldn't throw a type error with unrecognised strings (e.g. =
"false"), and doing so might make sense (although I do share Juliette's =
concerns about the BC-breaks).

Craig