Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117707
Message-ID: <5D843EFA-B0D1-4CF5-AB1B-0E6F224D7119@craigfrancis.co.uk>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D52FE706-F3B4-4A6D-AA9C-B92CEB2DF0A2"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Date: Tue, 10 May 2022 00:02:18 +0100
In-Reply-To: <CAMrTa2F10TkoR=iMQQELwJaWr9VcQ--sdnEZ38xNUpm-V9w1dg@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <CAMrTa2G6jqiUejTM2WCBmGRk=r34S81cC9AFvcPpc1CxBv-Jgw@mail.gmail.com>
 <B09FDF7D-FCDC-4D9D-BFE7-A60307222D27@craigfrancis.co.uk>
 <CAMrTa2F10TkoR=iMQQELwJaWr9VcQ--sdnEZ38xNUpm-V9w1dg@mail.gmail.com>
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: craig@craigfrancis.co.uk (Craig Francis)

--Apple-Mail=_D52FE706-F3B4-4A6D-AA9C-B92CEB2DF0A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 7 May 2022, at 22:11, Jordan LeDoux <jordan.ledoux@gmail.com> wrote:
> On Sat, May 7, 2022 at 1:38 AM Craig Francis <craig@craigfrancis.co.uk =
<mailto:craig@craigfrancis.co.uk>> wrote:
>=20
> Not what I'm going for... but anyway, to get an idea of your position, =
do you think the string '15' should be coerced to a number, or should it =
fatal error as well? e.g.
>=20
> $my_number =3D round($request->get('my_number'));
>=20
>=20
> '15' is not an undefined value.
>=20
> If a program uses the paradigm that null represents the equivalent of =
something like `unset($var)`


Hi Jordan,

Some programers can do that, but it's not how everyone sees it.

NULL is not the same as `unset()`, it is a value in itself, and many =
programmers simply give no thought to the distinction between an Empty =
String and NULL. e.g. when using the noted frameworks, NULL is provided =
for user values, and developers will often treat it the same as an Empty =
String... if `$name =3D=3D ''`, then show an error saying your name is =
required; if `strlen($name) > 200` then your name is too long, etc.



> What exactly would be the purpose of `?int` if this RFC was passed? To =
pass the value as null instead of 0?


I'll talk about `int` below; but just so I can focus on the nullability =
part of this question, I'll use `?string`...

Yes, that's all I'm proposing.

For example `?string` would not change (it will continue to provide the =
NULL value to the function), whereas `string` would coerce NULL to an =
Empty String, e.g.

```
function accept_nullable_string(?string $my_string) {
  var_dump($my_string);
}

function accept_string(string $my_string) {
  var_dump($my_string);
}

accept_nullable_string(3);     // string(1) "3"
accept_nullable_string('2');   // string(1) "2"
accept_nullable_string(true);  // string(1) "1"
accept_nullable_string(false); // string(0) ""
accept_nullable_string(NULL);  // NULL

accept_string(3);     // string(1) "3"
accept_string('2');   // string(1) "2"
accept_string(true);  // string(1) "1"
accept_string(false); // string(0) ""
accept_string(NULL);  // Currently TypeError, change to string(0) ""
```


> That's it?


Yep, but the point is about avoiding the upgrade problem when internal =
functions will stop coercing NULL, and instead throw type errors (these =
are hard to find, and will break code in seemly random places).



> What about `int|float`? Which one would it be coerced to?


Good question,

Short answer; today, if you pass the string '4' to a function that uses =
`int|float`, then it receives `int(4)`:

```
function accept_number(int|float $my_int) {
  var_dump($my_int);
}

accept_number('4'); // int(4)
```

Longer answer...

First I'll note the documentation says (for string to integer =
conversion) "If the string is numeric or leading numeric then it will =
resolve to the corresponding integer value, otherwise it is converted to =
zero (0)."

=
https://www.php.net/manual/en/language.types.integer.php#language.types.in=
teger.casting =
<https://www.php.net/manual/en/language.types.integer.php#language.types.i=
nteger.casting>

But an Empty String is not coerced to `int(0)` for user defined =
functions, or arithmetic (e.g. `5 + ""` complains after PHP 7.1)... =
whereas, an empty string is converted to 0 when using `intval($var)`, =
and `(int) $var`.

While I think this can be a bit harsh, I can see how it might avoid some =
ambiguity/issues, e.g. `$offset =3D ''; $a =3D substr('abc', $offset)`, =
although I have seen `substr('abc', NULL, $length)` a few times.

If PHP was to throw an exception for NULL to integer coercion with =
internal functions, while I recognise this would still create a BC break =
(e.g. `round($nullable)`), I'd might be fine with it, because an Empty =
String to Integer is also rejected.

That said, and back to your question about `int|float`, because the =
string '4' is coerced to `int(4)`, I'd prefer NULL to be coerced to =
`int(0)`.



> This pretty radically changes how typing itself would work in existing =
user programs.


I wouldn't say this is radical, considering it's just removing a single =
type error (I suspect it's rare for code to rely on NULL coercion =
triggering an exception)... in contrast, internal functions have always =
worked with null coercion, and works in other contexts like string =
concatenation (`'A' . $nullable`), =3D=3D comparisons, the =
print()/echo() functions, etc.



> What I'm saying is that for such a radical BC break you need to =
provide some compelling justification, and I'm concerned from your =
replies in this thread and the content of the RFC that you don't =
actually understand the extent of a BC-break you're proposing.


As noted previously, and the example I've added to the "Backward =
Incompatible Changes" section, I don't think this is a radical BC break, =
it's fairly small change designed to make NULL coercion work as =
documented, in a constant way (all contexts), and most importantly, =
avoid the upgrade problems for PHP 9.0 (please keep in mind the lack of =
tooling to help with this, where the only safe and easy way to handle =
this would be to add NULL coalescing throughout the code base, which is =
not a good idea).

Craig



--Apple-Mail=_D52FE706-F3B4-4A6D-AA9C-B92CEB2DF0A2--