Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112793
MIME-Version: 1.0
References: <CAF+90c9SQfb8G8gQ4o4o4thXauZx1qAeV_YZrC0wtTo9s+ornQ@mail.gmail.com>
 <CAHE1EdtRoj_5PdMZgvz9uWTXkgGSA_CCo39Q0d+MQbfezzxPYw@mail.gmail.com>
In-Reply-To: <CAHE1EdtRoj_5PdMZgvz9uWTXkgGSA_CCo39Q0d+MQbfezzxPYw@mail.gmail.com>
Date: Thu, 7 Jan 2021 12:45:11 +0100
Message-ID: <CAF+90c-tJkwuzRVPyesntvOjVU5FWmTeFmE6_hS3acyuggj_aA@mail.gmail.com>
To: Craig Duncan <php@duncanc.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000de5aa105b84df9f7"
Subject: Re: [PHP-DEV] [RFC] Deprecate passing null to non-nullable arguments
 of internal functions
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000de5aa105b84df9f7
Content-Type: text/plain; charset="UTF-8"

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

--000000000000de5aa105b84df9f7--