Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121631
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
In-Reply-To: <CAGBsUrfwRExOFZ8dRy0=D9wmKurkj4QBNPvOsmrw7Mh=rjX0mg@mail.gmail.com>
Date: Fri, 10 Nov 2023 10:47:16 +0000
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <1A044D32-019A-4152-A3C0-3F393974AC3B@craigfrancis.co.uk>
References: <CAFv4g+EqzB7whakuN-sr6YL2ih9xhHPzCsvTsEgJKMXBh9H9wQ@mail.gmail.com>
 <5144806E-E21F-4AF8-B9A2-0161561A6B9E@craigfrancis.co.uk>
 <CAGBsUrfwRExOFZ8dRy0=D9wmKurkj4QBNPvOsmrw7Mh=rjX0mg@mail.gmail.com>
To: Kamil Tekiela <tekiela246@gmail.com>
Subject: Re: [PHP-DEV] Passing null to parameter
From: craig@craigfrancis.co.uk (Craig Francis)

On 9 Nov 2023, at 16:08, Kamil Tekiela <tekiela246@gmail.com> wrote:
> Automatic casting of null to other types is a handy feature and =
deprecating it brings no benefit to anyone.=20

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?



> Instead, if you want, submit a proposal to reverse the direction.

No point, people will vote against, and will just entrench their =
position (people like to think they are right, this would involve them =
changing their mind; and because everyone voting is almost certainly =
using strict_types=3D1, it won't affect them, and they will see it as a =
way of pushing "lesser developers" to using strict types).



> This should only apply in loose-type mode.

Yep, of course.



> and it would make nullable types useless.

I don't think so, nullable would allow the NULL value, and the =
non-nullable would be coerced, just like the other types:

```
function example(string $b, ?string $c, int|float $a) {
  var_dump($b); // string(0) ""
  var_dump($c); // NULL
  var_dump($a); // int(5)
}

example(NULL, NULL, '5');
```



> Such a change could also be complicated to implement given how =
ambiguous it would be.

It always worked that way (for internal functions) - for arguments that =
accept a string, cast null to an empty string; if it accepts an integer =
then it's 0, etc.



> But if you can outline tangible benefits and write a PR to show how it =
would work, I think the community would review the RFC.=20

I can't be trusted to write C, so can't do a PR (other than to revert =
the last commit, which isn't quite right)... I did draft an RFC, but I =
just got complaints:

https://wiki.php.net/rfc/null_coercion_consistency



> As for the negative responses, it's probably because it's been many =
PHP versions since the nullable types were introduced. People accepted =
it and are generally satisfied with how it works.

People here are likely to be using `strict_types=3D1`, but the majority =
of developers use PHP as a simple scripting language, and don't see the =
benefit to strict type checks (just to note, I do, but I'm not talking =
about me, I'm looking at the amount of code that will not be able to =
upgrade to PHP 9).



> So unless it's causing some serious problems for PHP developers or =
users, I think it's too late to change the design of the language.

At the moment it's causing deprecation log entries (which are ignored), =
but the problems are everywhere, like the following (Laravel), is this =
really that unreasonable?

```
$a =3D trim($request->input('a'));
```

This will start getting Fatal Type Errors in 9.0... and finding these =
"mistakes" is close to impossible (phpstan doesn't find them; psalm =
requires high levels 1-3).

Craig