5 ms·

Why does 0 == "foo"?

by neals 6y ago

tyingq 6y ago
"If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number" And a string that doesn't look like a number at all is converted to 0. No, I'm not condoning this madness.
- coldtea 6y ago
  Well, in C you can cast any random set of bytes to an int, so there's that...
  - overgard 6y ago
    Sure but in C you usually do that explicitly, on purpose. Here it's almost certainly not what you wanted or expected.. Also, C is 20-30 years older and I don't think I've ever read anyone really compliment its type system in any way other than saying it's simple.
    - andreygrehov 6y ago
      If one doesn't know the language, they can write shitty code, regardless whether it's C or PHP. Any decent PHP programmer knows about the `===` operator that doesn't do any type juggling.
      - tyingq 6y ago
        This problem isnt really fixed with === per se. Converting strings to numbers is a common need, and the weird type conversation here is broken (and being fixed) for more than just implicit conversions in comparisons. The PHP team is calling it "saner numeric strings"...seems to indicate they agree.
totony 6y ago
"foo" is type casted into an int and, since it's not an int even when casted, it gets casted to a falsey 0. (int)"9" === 9 (int)"a" === 0 I assume this will cause backward incompatibility? I could see people relying on this instead of is_numeric. Not sure I like this change, since it introduces multiple ways of type casting (and therefore complexity). Before, it was obscure but simple, now, it'd be both obscure and not simple. EDIT: It will cause backward incompatibility https://wiki.php.net/rfc/string_to_number_comparison https://wiki.php.net/rfc/string_to_number_comparison I'm surprised this was 44 against 1 in the vote. Seems like it's very likely to cause issues. IMO they should just implement a "strict comparison" mode, where comparing different types throws a runtime exception. Or just deprecate "==" for "===".
- coldtea 6y ago
  >I'm surprised this was 44 against 1 in the vote. Seems like it's very likely to cause issues. On the other hand, seems very much like the kind of crap that you're better to rip the band-aid and fix, than to keep for an eternity lest the fix causes issues... >Or just deprecate "==" for "===". As if this would cause less issues?
  - totony 6y ago
    Automatic type conversion is prone to errors. Either they acknowledge that and force strict comparison (or add a way to do that), or they ignore and thus their change has no real effect, since mistakes will still happen with the new scheme. >As if this would cause less issues? Causing issues isn't the problem. Transparently breaking code is. Deprecating would give time for people to adapt their code and would warn them about the downsides or loose type conversion. Changing the semantics of loose comparison will make static analysis and finding potential issues way harder (and may post-pone finding the problems it introduces to years down the line). Adding a mode that warns/throws when encountering loose comparison would both make current code still work, and warn users of potential issues.
  - rectang 6y ago
    > you're better to rip the band-aid Not for silent failure. This soft of change means that tons of systems will fail in unexpected ways in unexpected places, and often people will never know about it. It's a security nightmare. Ripping the band-aid off is much more compelling when it will result in an exception. Silent failure, though. Ugh, if you actually care about writing reliable software, it's the worst.

Why does 0 == "foo"?

by neals 6y ago

Why does 0 == "foo"?

"If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number" And a string that doesn't look like a number at all is converted to 0. No, I'm not condoning this madness.

coldtea 6y ago
Well, in C you can cast any random set of bytes to an int, so there's that...
- overgard 6y ago
  Sure but in C you usually do that explicitly, on purpose. Here it's almost certainly not what you wanted or expected.. Also, C is 20-30 years older and I don't think I've ever read anyone really compliment its type system in any way other than saying it's simple.
  - andreygrehov 6y ago
    If one doesn't know the language, they can write shitty code, regardless whether it's C or PHP. Any decent PHP programmer knows about the `===` operator that doesn't do any type juggling.
    - tyingq 6y ago
      This problem isnt really fixed with === per se. Converting strings to numbers is a common need, and the weird type conversation here is broken (and being fixed) for more than just implicit conversions in comparisons. The PHP team is calling it "saner numeric strings"...seems to indicate they agree.

totony 6y ago

"foo" is type casted into an int and, since it's not an int even when casted, it gets casted to a falsey 0. (int)"9" === 9 (int)"a" === 0 I assume this will cause backward incompatibility? I could see people relying on this instead of is_numeric. Not sure I like this change, since it introduces multiple ways of type casting (and therefore complexity). Before, it was obscure but simple, now, it'd be both obscure and not simple. EDIT: It will cause backward incompatibility https://wiki.php.net/rfc/string_to_number_comparison https://wiki.php.net/rfc/string_to_number_comparison I'm surprised this was 44 against 1 in the vote. Seems like it's very likely to cause issues. IMO they should just implement a "strict comparison" mode, where comparing different types throws a runtime exception. Or just deprecate "==" for "===".

coldtea 6y ago
>I'm surprised this was 44 against 1 in the vote. Seems like it's very likely to cause issues. On the other hand, seems very much like the kind of crap that you're better to rip the band-aid and fix, than to keep for an eternity lest the fix causes issues... >Or just deprecate "==" for "===". As if this would cause less issues?
- totony 6y ago
  Automatic type conversion is prone to errors. Either they acknowledge that and force strict comparison (or add a way to do that), or they ignore and thus their change has no real effect, since mistakes will still happen with the new scheme. >As if this would cause less issues? Causing issues isn't the problem. Transparently breaking code is. Deprecating would give time for people to adapt their code and would warn them about the downsides or loose type conversion. Changing the semantics of loose comparison will make static analysis and finding potential issues way harder (and may post-pone finding the problems it introduces to years down the line). Adding a mode that warns/throws when encountering loose comparison would both make current code still work, and warn users of potential issues.
- rectang 6y ago
  > you're better to rip the band-aid Not for silent failure. This soft of change means that tons of systems will fail in unexpected ways in unexpected places, and often people will never know about it. It's a security nightmare. Ripping the band-aid off is much more compelling when it will result in an exception. Silent failure, though. Ugh, if you actually care about writing reliable software, it's the worst.