Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117006
Message-ID: <08953636-760b-2533-6c8f-a2cc57535d7e@telia.com>
Date: Mon, 7 Feb 2022 23:24:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.1
Content-Language: en-GB
To: Craig Francis <craig@craigfrancis.co.uk>, Sara Golemon <pollita@php.net>
References: <CAFv4g+Efz-V5V1uUedXpusNw6z-on=TT3kdWgC66SptSd8kB4g@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Reply-To: =?UTF-8?Q?Bj=c3=b6rn_Larsson?= <bjorn.x.larsson@telia.com>
In-Reply-To: <CAFv4g+Efz-V5V1uUedXpusNw6z-on=TT3kdWgC66SptSd8kB4g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: internals@lists.php.net ("Björn Larsson via internals")

Den 2022-01-02 kl. 00:17, skrev Craig Francis:
> 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 guess
>> the only objection I could have would be an academic one and I can't really
>> defend that.  So yeah, sure... why not?
>>
> 
> 
> Thanks Sara,
> 
> I've spent a few days coming up with a short(ish) list of parameters that
> 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-change.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.
> 
> Craig
> 
> 
> PS; starting new thread, as I have gone a bit off topic, original one at:
> https://externals.io/message/116519#116556
> 
Hi,

Thanks for this RFC! I think it could interesting to see how libraries
that needs to adapt to this are doing it IRL.

One example I have seen how to fix this for e.g. substr is to replace:
$result = substr($string, 0, $length)
with:
$result = substr($string ?? '', 0, $lenght)

So the null coalescing operator comes in quite handy ;-) Now if this is
a good way to solve it is another matter. But if you are a maintainer of
a library that works fine and wants to support PHP 8.1 this will solve
the upgrade in a smooth way.

Would be interesting to see how common this approach is for solving
PHP 8.1 upgrades for non-nullable arguments with internal functions?

I mean, it shows the value with the RFC from a slightly another angle.

Regards //Björn