Re: Allowing NULL for some internal functions

On 02.03.22 16:00, Craig Francis wrote:

I'll note that converting from NULL is used all the time, and is well defined:

https://www.php.net/manual/en/language.types.string.php "null is always converted to an empty string." https://www.php.net/manual/en/language.types.integer.php "null is always converted to zero (0)." https://www.php.net/manual/en/language.types.float.php "For values of other types, the conversion is performed by converting the value to int first and then to float" https://www.php.net/manual/en/language.types.boolean.php "When converting to bool, the following values are considered false [...] the special type NULL"

This is the behavior for explicit type casting (strval) and the implicit

casting when using a variable in a string context, like echo or print. This is basically just a base necessity - for example an array is converted to "Array". All information about the array is lost, except that the string is now called "Array". So would you say something like htmlentities should also accept array values and automatically convert it to the string "Array"? It is used all the time with echo and print, and it is well defined, yet it is still not a good idea. For strval and for echo it makes sense to convert an array to "Array" (barely, to end up with a somewhat useable string), but for parameter types it does not make sense. The same goes, in my opinion, for null.

It really depends on your code base... Laravel, Symfony, CakePHP, CodeIgniter (the frameworks I'm familiar with) all return NULL for missing GET/POST/COOKIE values, and that is a useful feature... but when the developer naively passes that to any one of those listed parameters, you will get a deprecation message in 8.1, and a Type Error in the future... and finding all of these is incredibly hard.

These frameworks change their types and signatures quite often - much more than PHP ever does. One Symfony project of mine that is now 7 years old has had crazy changes, both in types, signatures, directory structure, etc., yet people adapted and the changes were for the better. Compared to the changes produced by frameworks this deprecation about string values and null seems much smaller to me. And I do think it is important that coercions in the language become less frequent rather than more frequent, also because the language does have a certain "role model" effect. From 7.0 until 8.1 it was a legacy effect that converted null to an empty string, and only for internal functions, but with your proposal it would be an intentional decision to start treating null and scalar types more interchangeably.