Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116765
MIME-Version: 1.0
References: <CAFv4g+Efz-V5V1uUedXpusNw6z-on=TT3kdWgC66SptSd8kB4g@mail.gmail.com>
 <8a644158-9c54-f73d-ef74-79642f70f9c4@gmx.de>
In-Reply-To: <8a644158-9c54-f73d-ef74-79642f70f9c4@gmx.de>
Date: Sun, 2 Jan 2022 17:54:30 +0000
Message-ID: <CAFv4g+Ha+AtzWMoZuEcNK19yg5-GqmuniYRZAkKvTt+OSLw+cw@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003204cf05d49d1910"
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: craig@craigfrancis.co.uk (Craig Francis)

--0000000000003204cf05d49d1910
Content-Type: text/plain; charset="UTF-8"

On Sun, 2 Jan 2022 at 13:41, Christoph M. Becker <cmbecker69@gmx.de> wrote:

> [...]
> And then it's totally unclear to me how this is supposed to affect
> strict_types=1.
> [...]
> 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=0.  But frankly, in that case the original RFC[1] should
> not have passed, but it did, with 46 votes in favor, and *none* against.
>


I'm open to suggestions on how this should be handled, my RFC is just a
draft.

As to the original RFC, there wasn't really a discussion on it:

https://externals.io/message/112327

The only person who raised a concern was Craig Duncan.

And tbh, just scanning the RFC text, it's very reasonable, as consistency
is ideal... but I didn't realise how much code would need to be changed
until a few projects I work on started trying to use 8.1 (one team has gone
back to 8.0, although I'm hoping they will accept a custom error handler to
ignore these deprecation notices).

Craig

--0000000000003204cf05d49d1910--