Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117166
User-Agent: Cyrus-JMAP/3.5.0-alpha0-4778-g14fba9972e-fm-20220217.001-g14fba997
Mime-Version: 1.0
Message-ID: <69642616-72b7-44fe-97a7-27ae03bc8fce@www.fastmail.com>
In-Reply-To: 
 <CAC5V6gjianVuPo654_-mETYxsu0-eSo++Ez1yy81MNEcfwFq1Q@mail.gmail.com>
References: 
 <CAFv4g+Efz-V5V1uUedXpusNw6z-on=TT3kdWgC66SptSd8kB4g@mail.gmail.com>
 <CAFv4g+GDsq=w7qtSOVptEBiTTDZk2aeFCVGThVBR=0-xk=0oAA@mail.gmail.com>
 <983552d8-11f1-b5bc-fb82-148347982fda@gmx.de>
 <5494eaa7-2fa6-8364-9683-a2c8c9789d81@gmail.com>
 <CAC5V6gjianVuPo654_-mETYxsu0-eSo++Ez1yy81MNEcfwFq1Q@mail.gmail.com>
Date: Mon, 28 Feb 2022 11:42:06 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Feb 28, 2022, at 11:35 AM, Guilliam Xavier wrote:
> On Mon, Feb 28, 2022 at 5:41 PM Dik Takken <dik.takken@gmail.com> wrote:
>
>>
>> In my view, consistency between internal and userland functions brings a
>> lot of value, and not only for the language itself. As soon as internal
>> and userland become fully consistent it will become a lot easier to
>> write "internal" functions in PHP rather than C. Not only will that make
>> developing the standard library easier, it may also make the optimizer
>> and JIT compiler more effective. The more consistency the better.
>>
>
> Yes, and we see two possible ways to make them consistent w.r.t. handling
> of null argument passed into scalar parameter:
>
> 1. implicit coercion by default, error with strict_types=1
> 2. error (independent of strict_types)
>
> AFAIK, internal functions have been doing 1 since like forever, but PHP 7.0
> chose 2 for userland functions when introducing scalar parameter type
> declarations (see my previous message for history) and PHP 8.1 continued in
> that direction by deprecating 1 for internal functions (and planning to
> change them to 2 in PHP 9.0).
> Call me devil's advocate, but is it too late to discuss revisiting past
> decisions and consider changing direction towards 1 for userland functions
> (esp. in implications of BC impact)?

Under absolutely no circumstances should parameters become implicitly nullable.  That way lies madness.  And yes, coercing null to a magic zero-value is a form of implicit nullability.  Absolutely not, under any circumstances.

Bringing internal functions into line with user-space was the correct move.  There may be internals functions that make sense to be nullable on their own right, on a case by case basis.  We can evaluate that case by case.  

--Larry Garfield