On 2 Mar 2022, at 14:39, Andreas Leathley <a.leath...@gmx.net> wrote: > Type coercion already often does not work - giving the string "s" to an > integer-typed argument will lead to a TypeError, it will not be coerced. > I would prefer less coercions rather than more.
Hi Andreas, 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 > <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 > <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 > <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 > <https://www.php.net/manual/en/language.types.boolean.php> > "When converting to bool, the following values are considered false [...] the > special type NULL" > [...] but having to coerce null seems always avoidable to me, and null > is a special value explicitely. In my data null and an empty string > sometimes are two possible values, and automatic conversion seems like a > value judgement by the language that they are kind of similar, which > they should not be. 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. For consistency, the next step should be to deprecate or Type Error when doing this `setcookie('id', 123)` Craig
