Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116760
Message-ID: <8a644158-9c54-f73d-ef74-79642f70f9c4@gmx.de>
Date: Sun, 2 Jan 2022 14:41:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.4.1
Content-Language: de-DE
To: Craig Francis <craig@craigfrancis.co.uk>, Sara Golemon <pollita@php.net>,
 PHP internals <internals@lists.php.net>
References: <CAFv4g+Efz-V5V1uUedXpusNw6z-on=TT3kdWgC66SptSd8kB4g@mail.gmail.com>
In-Reply-To: <CAFv4g+Efz-V5V1uUedXpusNw6z-on=TT3kdWgC66SptSd8kB4g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 02.01.2022 at 00:17, Craig Francis wrote:

> On Thu, 2 Dec 2021 at 15:19, Sara Golemon <pollita@php.net> wrote:
>
>> On Thu, Dec 2, 2021 at 8:48 AM Craig Francis <craig@craigfrancis.co.uk>
>> wrote:
>>
>>> Is there any value in me proposing an RFC to update *some* internal
>>> functions so they can accept NULL?
>>
>> I'm not hard against this idea.  The interpretation of null in these
>> contexts as being equivalent to empty string isn't unreasonable.  I gue=
ss
>> the only objection I could have would be an academic one and I can't re=
ally
>> defend that.  So yeah, sure... why not?
>
> I've spent a few days coming up with a short(ish) list of parameters tha=
t
> are likely to receive `NULL`.
>
> The focus is on making it easier for developers to upgrade to newer
> versions of PHP. I'm thinking of the typical developer, probably using
> WordPress, isn't using Psalm (at levels 1 to 3, with no baseline), and
> isn't using `strict_types`; where they don't really have the time to add
> strval() to everything that could be NULL.
>
> Draft RFC:
> https://wiki.php.net/rfc/allow_null
>
> And the list, where I'm proposing we only relax this requirement for the
> *bold* parameters:
> https://github.com/craigfrancis/php-allow-null-rfc/blob/main/functions-c=
hange.md
>
> I'll give it a few weeks to see if there are any parameter suggestions
> (welcome via email, pull request, carrier pigeon, etc), then I'll start
> looking for the best way to implement this.

In my opinion, it makes no sense to special case some functions in this
regard; the selection of which parameters of which function to special
case will always be too long for some, and to short for others.  And
even if we find an acceptable compromise, what about functions of
external extensions (e.g. PECL packages, but also others, maybe private
packages).  We have not much, if any, say on these, but they will be
affected by the deprecation anyway.

And then it's totally unclear to me how this is supposed to affect
strict_types=3D1.  Either the respective string parameters are made
nullable unconditionally, so null would be accepted in strict mode as
well, what doesn't appear to be favorable.  Or do we want to special
case this kind of nullable parameters, so they are only nullable for
strict_types=3D0?  In my opinion, that would be the worst possible
outcome.  How should this even be documented?

If the BC break is deemed to serious (maybe for string parameters only),
we better consider to undeprecate this, although that would make
internal functions behave differently to userland functions for
strict_types=3D0.  But frankly, in that case the original RFC[1] should
not have passed, but it did, with 46 votes in favor, and *none* against.

[1] <https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg>

Christoph