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
