Re: Stricter implicit boolean coercions

Am 26.04.2022 um 11:54 schrieb Andreas Leathley <a.leathley@gmx.net>: > I have not found any past proposals or discussions to change boolean > coercions, so I would like to find out how the thoughts on internals are > to change this, or if there are any reasons not to change this that I > have not thought of. 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 > I can also see a case for allowing the strings 'true' and 'false', and > changing 'false' to be coerced to false, but that would be a BC break. I > am not sure if that is worthwhile. 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'. > Anything else would emit either a notice or a warning as a first step > (to be determined). My main goal would be to make these > probably-not-boolean usages more visible in codebases. Depending on the > feedback here I would create an RFC and try to do an implementation (to > then discuss it in more detail), so as of now this is mostly about > getting some basic feedback on such a change, and if someone else has > had any similar thoughts/plans. 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? Regards, - Chris