Re: Allowing NULL for some internal functions
| From: | Craig Francis | Date: | Sun, 02 Jan 2022 17:54:30 +0000 |
| Subject: | Re: Allowing NULL for some internal functions | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-116765@lists.php.net to get a copy of this message | ||
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