On Mon, 7 Feb 2022 at 15:15, Larry Garfield <la...@garfieldtech.com> wrote:
> The goal is consistency, so keep it consistent. I'd be happy with that. The only reason I've taken this approach is for developers using type checking to identify certain mistakes in their code (which can be useful); so I wanted to keep them happy by not changing any of the stricter "string only" arguments... that's why my patch silently makes PHP a bit more tolerant of NULL for the projects that aren't using `strict_types`... and, as noted before, I'm not suggesting all arguments - e.g. `NULL` is quite likely a bug for the `$characters` argument in `trim()`, and PHP probably should complain, even though an empty string does not. If there's an argument to be made to rewiden a type to include null, make > that case and have that debate on a function by function basis. I'm fine with that, but I worry people are underestimating the size of the problem (having a debate on each one would take a long time). I've put together my proposed list, it took a few days, and a lot of thought: https://github.com/craigfrancis/php-allow-null-rfc/blob/main/functions-change.md I've asked for suggestions and pull requests a few times, and the best I've got is `$path`/`$domain` for `setcookie()` (I disagree because `NULL` is often used for those arguments, so that `$secure` and `$httponly` can be set to true). At this point I think people should be suggesting why any of these function arguments should trigger a Fatal Error in PHP 9 if they receive NULL.. again, happy to discuss here; or off-list via email, video call, etc (thankfully, for my own mental health, the off-list messages have been positive)... or you can make suggestions on the repo: https://github.com/craigfrancis/php-allow-null-rfc/issues https://github.com/craigfrancis/php-allow-null-rfc/pulls
