Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Deprecate passing null to non-nullable arguments of internal functions »

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

php.internals

Nikita Popov

5 years ago
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

Sebastian Bergmann

5 years ago
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.

Larry Garfield

5 years ago
On Tue, Dec 1, 2020, at 8:57 AM, Nikita Popov wrote:
> 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

Josh Bruce

5 years ago
> On Dec 1, 2020, at 8:57 AM, Nikita Popov <nikita.ppv@gmail.com> wrote: > > 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 <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

Silvio Sparapano

5 years ago
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

Christoph Becker

5 years ago
On 02.12.2020 at 17:34, Silvio Sparapano wrote:
> 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] <https://www.php.net/manual/en/functions.internal.php> Regards, Christoph

tyson andre

5 years ago
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

Craig Duncan (PHP)

5 years ago
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()*

Nikita Popov

5 years ago
On Wed, Dec 16, 2020 at 10:50 PM Craig Duncan <php@duncanc.co.uk> wrote:
> 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

Nikita Popov

5 years ago
On Tue, Dec 1, 2020 at 3:57 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> 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