Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121640
Message-ID: <A95554B4-7282-4017-8D98-82C0A0FB7DD3@craigfrancis.co.uk>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_17856D39-BF0E-478E-9F52-06FC3B8DE57B"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
Date: Fri, 10 Nov 2023 12:25:36 +0000
In-Reply-To: <CAGBsUrf2TM65Sq-7LCzq2p6PN-EfhwfduYnPghxEY9W70-UqKg@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: Kamil Tekiela <tekiela246@gmail.com>
References: <CAFv4g+EqzB7whakuN-sr6YL2ih9xhHPzCsvTsEgJKMXBh9H9wQ@mail.gmail.com>
 <5144806E-E21F-4AF8-B9A2-0161561A6B9E@craigfrancis.co.uk>
 <CAGBsUrfwRExOFZ8dRy0=D9wmKurkj4QBNPvOsmrw7Mh=rjX0mg@mail.gmail.com>
 <1A044D32-019A-4152-A3C0-3F393974AC3B@craigfrancis.co.uk>
 <CAGBsUrf2TM65Sq-7LCzq2p6PN-EfhwfduYnPghxEY9W70-UqKg@mail.gmail.com>
Subject: Re: [PHP-DEV] Passing null to parameter
From: craig@craigfrancis.co.uk (Craig Francis)

--Apple-Mail=_17856D39-BF0E-478E-9F52-06FC3B8DE57B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On 10 Nov 2023, at 11:11, Kamil Tekiela <tekiela246@gmail.com> wrote:
>> That's what I thought, but for some reason, casting null is =
deprecated only when it's provided as an argument to functions, all =
other cases it's fine... weird right?
>=20
>=20
> No, passing null to non-nullable parameters is already an error. It =
has been for a long while now. The only exception are some built-in =
functions that silently ignored that and cast the value to another type.=20=


Not sure I'm following, I said "an argument to functions", the other =
cases I was referring to was string concatenation, =3D=3D comparisons, =
arithmetics, sprintf, print, echo, array keys, etc.



> However, passing null to non-nullable param was never allowed.=20

For user defined functions... but there are at least 335 parameters =
negatively affected by this deprecation:

=
https://github.com/craigfrancis/php-allow-null-rfc/blob/main/functions-cha=
nge.md

And that's ignoring the 104 questionable and 558 problematic parameters =
where NULL (or empty string) probably shouldn't be allowed (like how =
$separator in explode() already has a =E2=80=9Ccannot be empty=E2=80=9D =
Fatal Error).



> but as I explained earlier it was always an error. That's how the =
language was designed.

I'm not sure many people see it like that though, most of the frameworks =
can return NULL when retrieving GET/POST/DB etc values, and developers =
simply pass those nullable values to functions like trim(), urlencode(), =
hash(), base64_encode(), strtoupper(), preg_match(), etc.



> Finding it is difficult, I agree, but that's the whole purpose of the =
deprecation. It's supposed to help you find all the mistakes. The =
mistakes are only with built-in functions, so the scope is very limited.

Imagine a developer creating a simple search <form>, so the browser =
makes a request to "/search/?q=3Dx", and the developer works with the q =
value, maybe they use `htmlspecialchars`, or `preg_split` to separate =
the words, etc... during all of their (probably manual) testing, they =
are always providing a value, as they are using the website as they =
expect it to be used, but a few months later, when it's in production, a =
user types in the "/search/" URL, or edits the URL, or the page with the =
form on failed to load properly, or a browser extension did something to =
it; today the script would receive a NULL value, and it would be treated =
like an empty string (as expected and documented), but with PHP 9, this =
will cause a fatal error?



> Casting null to other types is not a mistake, but passing null to =
functions that don't expect it, is a mistake.

But that's what the type coercion is supposed to do, like how a function =
that expects an integer will accept the string '5'.



> Just think about a simple example and how ambiguous it would be.=20
>=20
> function abc(string|int $p) {}
> abc(null);=20
>=20
> What should null be converted into and why?

int(0), because union types already define an "order of preference":

https://wiki.php.net/rfc/union_types_v2#coercive_typing_mode

Like this:

```
function abc(string|int $p) {
  var_dump($p); // int(0)
}

abc(false);
```

Craig


--Apple-Mail=_17856D39-BF0E-478E-9F52-06FC3B8DE57B--