This week we fixed 3 different '0' is falsey in #PHP bugs in #MediaWiki
ahhhhhhhhhhhhhhhhhh
I started some notes about what it would take to get rid of this from PHP, code-wise it's literally one line. But of course the real battle is convincing people it's a misfeature that is actively harmful.
@legoktm Not sure if I should be editing this in directly or whether it's useful, but Perl also treats the string "0" as falsey, to the point that the builtin ioctl and fcntl functions map zero-valued success returns to literally the string "0 but true", which is also specially exempt from runtime warnings about numeric conversions on not-fully-numeric strings.
@dasyatidprime please, feel free to edit the page directly with that and any other commentary/feedback - it's a wiki :)
I had no clue Perl did that, TIL. That's pretty wild.
@legoktm Added Perl. Also checked Tcl, since it's stringly typed. (Tcl also treats "false", "no", "off", "f", and "n" as false, AFAICT, but it's even more fully stringly typed than Perl or PHP, so…)
@dasyatidprime thanks! I'm now curious as to why PHP added this in the first place, and if it was "inspired" by something else. Added a note to look into that...
@legoktm AFAIR, PHP falls into that general class of languages where the numeric/string type boundary is weak. In those contexts, it's harder to gauge what a general-purpose semantic should be. Treating string-zero as falsey is similar to saying "booleans are converted via the numeric side", which is coherent-ish but leads to people missing edge cases when they want to write "string is nonempty" and instead write "string is nonempty and not numeric zero".
@legoktm The opposite problem can also show up, in theory. If you're getting what are semantically numerics from a source that's giving you string representations, in a way where all your math etc. does the conversion implicitly anyway so you never do it yourself, and you want to test for them being nonzero, then if string-zero is truthy then your condition breaks—though that's more likely to be obvious in testing.
@legoktm (Also I should have said something more like “booleans prioritize the numeric side” above.)
@legoktm One good question would be whether this is a problem in JavaScript/ECMAScript code, which does implicit string/numeric conversion but makes the opposite decision on string-zero.
Lua, interestingly, does string/numeric implicit conversion (though I think it's been tightened up over time) and treats _both_ numeric and string zero as truthy because it has a separate boolean type regardless.