On 26.04.22 14:47, Christian Schneider wrote:
There are two big reasons: - BC: Checking for the truthiness of a value is very common and would require a lot of code changes. - Some of us like the conciseness of "if ($foo) ...", see below
That would not be my target - in an if expression a lot more values are allowed anyway (arrays, objects, etc.), so this is not about determining truthiness, but actual conversions to a bool type, like a bool parameter, a bool return type or a bool property type. The inspiration for this is the "Deprecate implicit non-integer compatible float to int conversions" (https://wiki.php.net/rfc/implicit-float-int-deprecate), minus the mathematical expressions that were considered there. It is about avoiding probably-unintended values being coerced to boolean and therefore losing information / adding unnoticed bugs to a codebase.
I'm definitely against adding more special cases like 'false'. Side-note: Removing something like '0' => false is also a BC break, not just adding 'false'.
I am not suggesting removing the coercion from the string '0' to false or changing anything about that.
One of the big issues I have with this (as well as undefined variables not being allowed in if ($foo)) is that the replacement constructs are clunky: if ($foo) =>. if (!empty($foo)) For me this is quite a regression in readability but then again that's a matter of taste. And would !empty($foo) even work in your world or how would empty() be defined?
empty is also not something I would consider covering, as there you also do not need a conversion to a bool type. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php