Req #39579 [Nab]: Comparing zero & string values in boolean comparison has unexpected behaviour

Edit report at https://bugs.php.net/bug.php?id=39579&edit=1 ID: 39579 User updated by: iain at workingsoftware dot com dot au Reported by: iain at workingsoftware dot com dot au Summary: Comparing zero & string values in boolean comparison has unexpected behaviour Status: Not a bug Type: Feature/Change Request Package: Variables related Operating System: FreeBSD 6.1 PHP Version: 5.2.0 Block user comment: N Private report: N New Comment: When I posted this as a bug initially I was about to turn 26. 5 months ago I turned 40. Thanks for the follow up Niki, long live PHP! Previous Comments: ------------------------------------------------------------------------ [2021-04-14 20:53:04] nikic@php.net > I wonder why this problem has not been solved so far. It so happens that this problem *has* been solved, in PHP 8.0. Please see https://wiki.php.net/rfc/string_to_number_comparison for more information. ------------------------------------------------------------------------ [2021-04-14 20:48:08] ehsan at chavoshi dot no--spam dot com This behavior has the potential to cause many logical errors.At the same time, it is not easy to change it, and changing it also causes logical errors in existing programs. My strong suggestion is to throw a E_NOTICE when the result of the comparison would have been different if the typecasting had not been done. (or anytime typecasting occurred when comparing two values) . showing a safe NOTICE attracts the programmer's attention and at the same time does not cause any problems in running programs. I wonder why this problem has not been solved so far. ------------------------------------------------------------------------ [2020-06-19 16:24:55] amfriedman at gmail dot com This "feature" just burned an hour of my time as I wracked my brain trying figure out why a continue; statement in my foreach loop was being triggered. I had an value of (int) 0 in one of the array items, and it passed an if-test that compared it to a particular string. Super frustrating. I think PHP should generate a Notice to give the developer a head's up about this "gotcha". ------------------------------------------------------------------------ [2014-05-28 13:53:44] rasmus@php.net The transitive property of equality doesn't apply to a type-coercing equality check because the types matter in each comparison. So you can't say that since 0 == '0' and 0 == 'a' then '0' must be equivalent to 'a'. In the first two comparisons you are comparing integers to strings and in the last one you are comparing two strings. These are completely different situations for a type-coercing equality operator like == If you don't want to juggle types, simply use === ------------------------------------------------------------------------ [2014-05-28 13:25:20] tom at r dot je To expand on my point above: 0 == '0' //TRUE Here, 0 and '0' are equivalent. However: 0 == 'a'; //TRUE '0' == 'a'; //FALSE Here, 0 and '0' are not equivalent which is very inconsistent. If 0 is equivalent to '0' and 0 is equivalent to 'a' than it logically follows that '0' is equivalent to 'a'; which is clearly not the case, and nor should it be to fix this logical contradiction the only option is to make 0 and 'a' not equivalent. As for the problems presented above about actually implementing a change, why not do what's been done before and add an INI setting (settable via ini_set). Any scripts which do rely on this broken functionality can just call ini_set for compatibility with the old operator. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=39579 -- Edit this bug report at https://bugs.php.net/bug.php?id=39579&edit=1