Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117184
MIME-Version: 1.0
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>
 <69642616-72b7-44fe-97a7-27ae03bc8fce@www.fastmail.com> <CAFv4g+F0HOgCgeUyiG06qhxQnWbVCN2aaP=a2CJT9tkbMP7kLg@mail.gmail.com>
 <7fbed755-42e2-d023-285f-39863a97f297@gmx.de> <3665C848-B4C3-4528-AEFA-02C868748AA8@cschneid.com>
 <0b5bc29d-3814-0e1d-b94a-47790019c778@gmx.de>
In-Reply-To: <0b5bc29d-3814-0e1d-b94a-47790019c778@gmx.de>
Date: Tue, 1 Mar 2022 18:10:54 +0000
Message-ID: <CAFv4g+HPm+edmgnPAGwBk=4EJxj2can--iWfgtMasrYHk6pLww@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Christian Schneider <cschneid@cschneid.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ab524205d92c168c"
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: craig@craigfrancis.co.uk (Craig Francis)

--000000000000ab524205d92c168c
Content-Type: text/plain; charset="UTF-8"

On Tue, 1 Mar 2022 at 10:43, Christoph M. Becker <cmbecker69@gmx.de> wrote:

> I said, the BC break doesn't appear to be *that* serious.
>


It is when it's a Fatal Error, and there are lots of them :-)



> To elaborate: in my opinion, it is a good thing if internal functions
> and userland functions behave the same regarding parameter types.



Yes, agreed.


However, picking *some* functions and make *some* of their parameters
> nullable does not look reasonable to me.



Also agreed... while I did start with that suggestion, I'm uncomfortable
with making some parameters nullable due to how it would affect those using
`strict_types` (where it can be a good check for some oddities).


Since it has been brought up multiple times that it is hard to find all
> occurrences which would have to be adapted, I suggested a somewhat
> viable solution for userland code (namely to define userland functions
> which establish the old behavior; and of course, you'd need some tooling
> to replace the original function calls).



But that's a lot of work, and creates even messier code...

I'm pretty confident the best solution is to keep all parameter types the
same (I could argue that some parameters could do with a "cannot be empty"
exception, to reject NULL and an Empty String, but that would be a
different RFC)... and anyone using `strict_types` will still have a Type
Error when they pass a value of the wrong type to these parameters... the
*only* change is for those not using `strict_types`, for NULL to still be
coerced to a string/int/float/bool, as it always has been for internal
functions... and I think this can be done to user functions as well, as
developers not using strict_types won't have cared about this before.

Craig

--000000000000ab524205d92c168c--