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
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.
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
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
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
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
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
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()
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
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