On 02.01.2022 at 00:17, Craig Francis wrote: > On Thu, 2 Dec 2021 at 15:19, Sara Golemon <poll...@php.net> wrote: > >> On Thu, Dec 2, 2021 at 8:48 AM Craig Francis <cr...@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? > > 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.
In my opinion, it makes no sense to special case some functions in this regard; the selection of which parameters of which function to special case will always be too long for some, and to short for others. And even if we find an acceptable compromise, what about functions of external extensions (e.g. PECL packages, but also others, maybe private packages). We have not much, if any, say on these, but they will be affected by the deprecation anyway. And then it's totally unclear to me how this is supposed to affect strict_types=1. Either the respective string parameters are made nullable unconditionally, so null would be accepted in strict mode as well, what doesn't appear to be favorable. Or do we want to special case this kind of nullable parameters, so they are only nullable for strict_types=0? In my opinion, that would be the worst possible outcome. How should this even be documented? 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. [1] <https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg> Christoph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
