# [RFC] Deprecate passing null to non-nullable arguments of internal functions - Thread: https://externals.io/message/112327 - Original archive: https://news-web.php.net/php.internals/112327 - Started by Nikita Popov on 2020-12-01T14:57:55+00:00 - Messages: 10 - RFC: Deprecate passing null to non-nullable arguments of internal functions (Implemented (PHP 8.1)) — https://externals.io/rfc/deprecate_null_to_scalar_internal_arg.md - RFC: NULL Coercion Consistency (Withdrawn) — https://externals.io/rfc/null_coercion_consistency.md - 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 --- ## #112327 — Nikita Popov — 2020-12-01T14:57:55+00:00 URL: https://externals.io/message/112327#112327 Hi internals, I've put up an RFC to make the handling of "null" arguments consistent between internal and user-defined functions: https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg I started an informal discussion for this change during the 7.4 cycle already, but decided to postpone the change at the time. Regards, Nikita --- ## #112328 — Sebastian Bergmann — 2020-12-01T15:16:44+00:00 URL: https://externals.io/message/112327#112328 · In reply to: #112327 Am 01.12.2020 um 15:57 schrieb Nikita Popov: > I've put up an RFC to make the handling of "null" arguments consistent > between internal and user-defined functions: Makes sense to me, +1. --- ## #112363 — Larry Garfield — 2020-12-01T20:40:20+00:00 URL: https://externals.io/message/112327#112363 · In reply to: #112327 > Hi internals, > > I've put up an RFC to make the handling of "null" arguments consistent > between internal and user-defined functions: > > https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg > > I started an informal discussion for this change during the 7.4 cycle > already, but decided to postpone the change at the time. > > Regards, > Nikita Seems well thought-out to me. Endorse. --Larry Garfield --- ## #112364 — Josh Bruce — 2020-12-01T21:21:35+00:00 URL: https://externals.io/message/112327#112364 · In reply to: #112327 > > > I've put up an RFC to make the handling of "null" arguments consistent > between internal and user-defined functions: > > https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg > > I started an informal discussion for this change during the 7.4 cycle > already, but decided to postpone the change at the time. For what it’s worth, you had me at more consistent (and constrained) use of “null”. Cheers, Josh --- ## #112375 — Silvio Sparapano — 2020-12-02T16:34:03+00:00 URL: https://externals.io/message/112327#112375 · In reply to: #112364 Hello, IMHO it’s only a declaration issue. In other terms, if documentation of strlen says: strlen ( string $string ) : int then I mean that $string MUST be a string, and return value MUST be an int. But then we found that if $string is null, zero is returned. If $string is an array, null is returned … We simply need consistency between how a function is documented, and how it really works. I mean, it may also be convenient for strlen to accept a parameter type other than string (such as null), but it must be well documented. Da: Josh Bruce Inviato: martedì 1 dicembre 2020 22:21 A: Nikita Popov Cc: PHP internals Oggetto: Re: [PHP-DEV] [RFC] Deprecate passing null to non-nullable argumentsof internal functions --- ## #112376 — Christoph M. Becker — 2020-12-02T16:52:15+00:00 URL: https://externals.io/message/112327#112376 · In reply to: #112375 > Hello, > IMHO it’s only a declaration issue. > > In other terms, if documentation of strlen says: > > strlen ( string $string ) : int > > then I mean that $string MUST be a string, and return value MUST be an int. > > But then we found that if $string is null, zero is returned. If $string is an array, null is returned … > We simply need consistency between how a function is documented, and how it really works. > I mean, it may also be convenient for strlen to accept a parameter type other than string (such as null), but it must be well documented. It is reasonably well documented: | If the parameters given to a function are not what it expects, such as | passing an array where a string is expected, the return value of the | function is undefined. In this case it will likely return `NULL` but | this is just a convention, and cannot be relied upon. [1] Regards, Christoph --- ## #112388 — tyson andre — 2020-12-03T02:14:25+00:00 URL: https://externals.io/message/112327#112388 · In reply to: #112327 Hi Nikita, > I've put up an RFC to make the handling of "null" arguments consistent > between internal and user-defined functions: > > https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg > > I started an informal discussion for this change during the 7.4 cycle > already, but decided to postpone the change at the time. Sounds like a good idea - available open source static analyzers are much better than they were when php 7.0.0 was released, and php now has nullable types, union types and property types. E.g. Phan already warns about passing null/nullable to internal functions as strictly as user-defined functions, partly because I'd assumed internal functions would change in the future. https://phan.github.io/demo/?code=%3C%3Fphp%0Afunction+test%28%3Fstring+%24str%29+%7B%0A++++return+strlen%28%24str%29+%2B+strlen%28null%29%3B%0A%7D (10MB webassembly demo) Regards, Tyson --- ## #112531 — Craig Duncan — 2020-12-16T21:49:48+00:00 URL: https://externals.io/message/112327#112531 · In reply to: #112327 While making internal functions treat non-nullable types consistently with userland is an absolute win, I do wonder if it should be done simultaneously with changing some functions to formally accept nulls. I'm thinking back to all the pain caused when *count() *starting raising a warning for null values. We saw a lot of code that passed undeclared variables to *count()* and I can imagine people writing similar code with something like *strlen()* --- ## #112793 — Nikita Popov — 2021-01-07T11:45:11+00:00 URL: https://externals.io/message/112327#112793 · In reply to: #112531 > While making internal functions treat non-nullable types consistently with > userland is an absolute win, > I do wonder if it should be done simultaneously with changing some > functions > to formally accept nulls. > PHP 8 made quite a few function/method arguments nullable to fix various behavior consistency issues. That said... I'm thinking back to all the pain caused when *count() *starting raising a > warning for null values. > We saw a lot of code that passed undeclared variables to *count()* > and I can imagine people writing similar code with something like > *strlen()* > I don't think that making the argument of `strlen()` nullable is in any way appropriate. This is a case where people will just have to fix their code. I do think we can relax certain type requirements on a case by case basis (e.g. the fact that ini_set requires a string rather than any scalar value seems unnecessarily pedantic), this just isn't one of those cases. Generally making arguments nullable mostly applies to arguments that are optional. Regards, Nikita --- ## #112936 — Nikita Popov — 2021-01-20T09:01:32+00:00 URL: https://externals.io/message/112327#112936 · In reply to: #112327 > Hi internals, > > I've put up an RFC to make the handling of "null" arguments consistent > between internal and user-defined functions: > > https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg > > I started an informal discussion for this change during the 7.4 cycle > already, but decided to postpone the change at the time. > > Regards, > Nikita > I plan to start voting on this RFC soon. Nikita