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

- Thread: https://externals.io/message/116076
- Original archive: https://news-web.php.net/php.internals/116076
- Started by Craig Francis on 2021-09-17T15:02:04+00:00
- Messages: 1
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #116076 — Craig Francis — 2021-09-17T15:02:04+00:00

URL: https://externals.io/message/116076#116076

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