On Wed, 2 Mar 2022 at 15:21, Andreas Leathley <a.leath...@gmx.net> wrote:
> 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. > But that's what the RFC is about. Although you do raise a good point, why does `print(NULL)` not complain? Think about htmlspecialchars(1), that integer is going to be cast to the string '1', in exactly the same way that NULL is cast to the string ''. 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"? Oddly, I'm fine with `htmlentities(array())` being rejected, because it has always been rejected... and, arrays/objects cannot be easily coerced to a simple value (null can be, and is). My focus is about not needlessly breaking code that works, I want everyone to upgrade to PHP 9... you will notice I'm not complaining about the fairly easy to implement `#[ReturnTypeWillChange]`, the change for `mysqli_report()`, or the change I made for `htmlspecialchars()` to ensure single quotes are encoded by default... but tracing very variable from source to sink, that is *hard*. > 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 Yes, but, as noted, returning NULL for a missing value is useful... I highly doubt they will change these function signatures so the default is an empty string, and make the return value always a string. Compared to the changes produced by frameworks this deprecation about > string values and null seems much smaller to me. It's a small problem today, because it's a new deprecation (note how WordPress is just telling people to ignore it)... the problem comes when it becomes a Fatal Error. 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. > I am not making it more frequent, it's how it has ways worked (with the oddity of user defined functions that specified parameter types); if you don't like coercion, that's fine and good, but you should be using `strict_types`... if PHP isn't going to support any coercion, then also fine, but deprecate it all (and accept the consequences). Craig
