#48012 [Opn->WFx]: String "0" conversion to boolean FALSE is not logical.

ID: 48012 Updated by: rasmus@php.net Reported By: dave at ifox dot com -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: All PHP Version: 5.3.0RC1 New Comment: PHP is first and foremost a Web language, not a general-purpose scripting language. Since the Web is not typed and everything is a string, I had to do things slightly differently early on to make PHP do what people expected. Specifically, "123"==123 needs to be true in order to not have to type cast every single numeric user input. Given that, then it also follows that '0'==0 and if you continue with that and consider that 0==false then it makes sense that '0'==false. However, '0'===false is, of course, false. This is why we have the strict type-comparison operators in PHP. Basically if we change '0' to be true, then we also have to trickle that change up resulting in '123'!=123 which would break every app out there. So, while I understand your point, it simply isn't going to happen. Previous Comments: ------------------------------------------------------------------------ [2009-04-18 19:05:48] dave at ifox dot com Description: ------------ PHP Developers, I typed a very logical explanation of why more careful thought should have been put into the addition of this conversion: "0" => FALSE but the submission failed and so I will try to reproduce it. When I learned about the exception of the string "0" converting to a boolean false, I had a sick feeling in my stomach. An entire team of language developers fell down the slippery slope caused by a handful of programmers in 2003 and 2004 that wanted to shorten their code, and thought that "0" -> TRUE was a bug. Every other language in existence converts a non-empty string to a boolean TRUE, because they prevail in this logic: the only meaning that SHOULD be derived from an alphanumeric string is its alphanumeric content, unless first cast to a numeric (or other) type. For a language that tries to bring in the best of other languages, PHP should at least mimic the logical behavior of those languages. I have edited dozens of web sites to fix well-structured code by skilled programmers that didn't expect this behavior, particularly when checking for the existence of strings from databases or user input (form POSTs). As an example: if ($_POST["uid"] && ...) { ... } now must be changed to: if (strlen($_POST["uid"]) && ...) { ... } and sometimes there are dozens of these in series. This begs programmers to be sloppy and just let "0" fail as an unusual case even when valid as input. And even skilled programmers can't be expected to read and catch this tiny exception in your documentation. There are other ramifications from not respecting the alphanumeric string for the purpose it was intended, to hold alphanumeric values. I will not expound here. The fact that FORM POSTs yield strings is not something to streamline in to the assumption that a user "meant" to enter an integer. Only a beginning programmer wanting a shortcut hack would expect or want this behavior. And what of " 0", "0 ", "00", "false", and "0.0"? They are respected! Originally I thought the "0" conversion was an attempt to make bool(string(FALSE)) == FALSE, but it already does since string(FALSE) == "" (although in other languages, it yields TRUE, because it is appropriate to conclude that the string representation of any boolean value has length and is therefore TRUE). JavaScript, as a common example, understands what an alphanumeric string is for: <script> if ('0') document.write('YES'); </script> This yields "YES", of course. Unfortunately there are now people out there posting that JavaScript is broken. But they are beginners, of course. A language should never make assumptions about a programmer's users' intent when providing input. If a user intends "0" as a string, why assume that is a numerical value? Don't you need to now assume all sorts of zero-value strings? I have developed two loosely-typed languages, and I made the choice to treat non-empty strings as TRUE. I find PHP for the web very usable, but I was completely surprised by this choice, and I'm sorry to say that it has resulted in high-quality code yielding unexpected subtle failures for its users. I modified PHP (14 or so changes in the Zend engine) to remove the feature and I made a patch. The ill stomach went away, and PHP now respects alphanumeric strings, but now I am uniquely conscious in a world of assumptions yielding unexpected results. I guess that's the beauty and curse of open source. What were the thought processes in creating this "feature"? Please consider its removal! Dave May Reproduce code: --------------- $str = "0"; if ($str) echo "TRUE"; else echo "FALSE"; --- From manual page: language.types.boolean --- Expected result: ---------------- TRUE Actual result: -------------- FALSE ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=48012&edit=1