[RFC] Deprecate passing null to non-nullable arguments of internal functions

From: Date: Fri, 17 Sep 2021 15:02:04 +0000
Subject: [RFC] Deprecate passing null to non-nullable arguments of internal functions
Groups: php.internals 
Request: Send a blank email to internals+get-116076@lists.php.net to get a copy of this message
Hi Internals, https://externals.io/message/112327 https://externals.io/message/112996 Considering how frequently developers use this pattern: $name = ($_POST['name'] ?? NULL); Sometimes without really noticing, e.g. - Laravel: $request->input('name'); - Symfony: $request->get('name'); - CakePHP: $this->request->getQuery('name'); - CodeIgniter: $request->getGet('name'); I'm concerned it's going to make upgrading to 8.1 fairly annoying, as these NULL values get passed to strlen(), trim(), strpos(), htmlspecialchars(), strtoupper(), hash(), simplexml_load_string(), strtotime(), etc. I appreciate projects using strict_types=1 will prefer this, but I suspect all the deprecation notices will be annoying for the majority of projects that don't. And I appreciate that each instance is easy to fix, but there is a lot of them out there (says he trying out a few projects on 8.1.0RC2, and being glad that I'm not the one who needs to find and explicitly change all of these potential NULL values to an empty string). As an aside, it is useful having NULL to differentiate between a GET/POST/etc value not being present, vs the value being explicitly set to an empty string. And anyone using Laravel, remember that error_reporting(-1) is used in HandleExceptions.php (to report all errors), and E_DEPRECATED is handled via ErrorException, which is likely to result in 500 errors for you... same with "Return type of X should either be compatible with X, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice" (lots of those, hopefully all will be fixed soon). Craig

« previous php.internals (#116076) next »