Re: Allowing NULL for some internal functions

On 02.01.22 00:17, Craig Francis wrote:

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.

I don't think the current deprecation notices are a real hindrance in upgrading to a newer PHP version - there have been many such changes which require possibly many small adaptions in code in the past, like making undefined array keys a warning in PHP 8.0 (which seems a lot more radical than adding the current deprecation notices). Singling out this specific deprecation/change as impactful seems a bit overblown. I also feel like such an un-deprecation would be premature. PHP 8.1 has only just come out, the road until PHP 9.0 is still quite long, and deprecation notices can easily be ignored for now, for those who do not want to change their code right away. If in a year or two this is a big problem in real code, then there would at least be a basis for changing it, but I suspect most codebases will see more benefit in handling their types more properly than if the language "sometimes" automatically converts null to an empty string without complaining about it. I did have some occurances of this deprecation notice in my applications when upgrading to 8.1, and each time it was clearly a bug or oversight. Removing the deprecation notices would also remove those insights into possibly unreliable code.