Re: Passing null to parameter

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. 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