On 9 Nov 2023, at 16:08, Kamil Tekiela <tekiela...@gmail.com> wrote:
> Automatic casting of null to other types is a handy feature and deprecating
> it brings no benefit to anyone.
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=1, 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.
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=1`, 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 = 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
