Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116155
MIME-Version: 1.0
References: <CAJp_myX3J8gUb3885KAdEz+xokpZ_mz1Gs_DrN2Tp+JYfewcEw@mail.gmail.com>
 <CAF+90c_JR1mUrgHFkfYYZi2TuSmkaF3hmvT03rfW7kGnhkZf6Q@mail.gmail.com>
In-Reply-To: <CAF+90c_JR1mUrgHFkfYYZi2TuSmkaF3hmvT03rfW7kGnhkZf6Q@mail.gmail.com>
Date: Sat, 25 Sep 2021 12:24:40 +0100
Message-ID: <CAFv4g+GNmKNVsTMTo5wHPD7KiF_LTUDv=5wt-+Rke28Ko9qC1Q@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: "Matthew Weier O'Phinney" <mweierophinney@gmail.com>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e620f805ccd01c1e"
Subject: Re: [PHP-DEV] BC breaking changes in PHP 8.1
From: craig@craigfrancis.co.uk (Craig Francis)

--000000000000e620f805ccd01c1e
Content-Type: text/plain; charset="UTF-8"

On Thu, 23 Sept 2021 at 17:53, Nikita Popov <nikita.ppv@gmail.com> wrote:

> I believe the changes in PHP 8.1 with the highest migration burden for
> open-source libraries are the additional of tentative return types (aka
> "put #[ReturnTypeWillChange] everywhere") and deprecation of null arguments
> to internal functions, followed by the float to int precision-loss
> deprecation and, depending on project, the Serializable deprecation.
>
> [...]
>
> I'm not sure what we can do about that though. Sure, we could stop with the
> (runtime) deprecations, only document the change and then directly
> implement it at the next major version. That would be much simpler for us
> (generating runtime deprecations is actually a major implementation pain,
> as well as a big performance concern) and would make minor version upgrades
> for libraries much simpler. However, it also removes the ability to address
> problems before they turn into fatal errors, e.g. by recording any stray
> deprecation warnings in production.
>


While "put #[ReturnTypeWillChange] everywhere" has been fairly easy...
"deprecation of null arguments to internal functions" is a major issue,
because they are everywhere, and only really found at run-time... and tbh,
I can't explain to anyone why it's so important this will be broken in the
future, especially for the majority of projects who are not using
`strict_types=1`.

Don't get me wrong, a user/library defined function that says it only wants
a string, I get that, but they have full control over it (for their
projects) so they can be as strict as they like, or use `?string`... but
the internals functions have always accepted NULL, and used by everyone.

As I noted last week, frameworks use NULL for undefined GET/POST/COOKIE
values, so these NULL get everywhere; and it can be useful to distinguish
between a value that wasn't set vs an empty string (e.g. when saving to a
database, a NULL can be "do not change", which is different to "set this
field to an empty string").

One of the projects I work with have gone down the route of "check it, but
you should probably stick `strval()` in every case of `strlen()`, `trim()`,
`strpos()`, `htmlspecialchars()`, `strtoupper()`, `hash()`,
`hash_equals()`, `simplexml_load_string()`, `strtotime()`, `explode()`,
etc"... which really doesn't seem sensible (one commit was over 200
manually checked/changed lines, and took about 3 days)... the other
projects have gone with the "we can stick on 8.0 for a while, hopefully
things change".

Maybe PHP 8.1 could be updated so these string functions could continue
accepting NULL?

Craig

--000000000000e620f805ccd01c1e--