Re: [RFC] Deprecate passing null to non-nullable arguments of internal functions
| From: | Nikita Popov | Date: | Thu, 07 Jan 2021 11:45:11 +0000 |
| Subject: | Re: [RFC] Deprecate passing null to non-nullable arguments of internal functions | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-112793@lists.php.net to get a copy of this message | ||
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