[stevekemp]

'foobar' is coerced into a number, which fails for the obvious reason. So it becomes 0, which means the expression is "0 == 0".

Terrible, terrible, behaviour but there are lots of similar examples in PHP because it evolved over time rather than being designed as-is. Some of these things are being fixed over time, like this very example, others can't/won't be.

[Zancarius]

> Terrible, terrible, behaviour but there are lots of similar examples in PHP

So true.

One I ran into recently was comparing hashes that start with '0e' and contain only a numeric component after that prefix. Failure to use the identity operator means that you can have two different hashes returning... equality. PHP apparently thought it a good idea to coerce that into 0 raised to an exponent, which of course always yields zero. e.g.:

    php > var_dump('0e41235843934' == '0e61193475532');
    bool(true)

Yeah, I know: The correct (and only) way to write this is to use the identity operator (===) but it's not at all intuitive. For those of us who are used to this it's fine since it's a force of habit, but for those who aren't it'll lead to unexpected behaviors. The only saving grace is that the quality of PHP code out there has been slowly (slowly!) improving over time, thanks in part to composer and ecosystem/cultural changes.

But it's also not outside the realm of possibility that someone won't eventually forget to add an extra '=' and induce a very difficult bug to isolate...

[jontro]

Is this fixed in php 8? I did not think this was possible as there is no type coercion and not well documented. [1][2]

Noticed "0.2" == "0.20" as another example

[1] https://www.php.net/manual/en/language.operators.comparison.... [2] https://www.php.net/manual/en/language.types.type-juggling.p...

[Zancarius]

> Is this fixed in php 8?

I don't know. It's one of those cases where fixing it to do the "right" thing would potentially break a lot of software depending on this sort of erroneous behavior. Part of me wants to say "I hope so" and part of me is kinda terrified at what might happen if they did. Shouldn't be difficult to fix, but it would definitely take some time.

Someone should know if there's a decent linter that would pick this up to make it easier to fix, I would imagine!

> I did not think this was possible as there is no type coercion and not well documented.

I think when applying the equality operator (==) in lieu of the identity operator (===) between strings PHP uses heuristics to decide what to do. If it looks like a number, it coerces it into an int or a float. As an example:

    php > var_dump('1e12' == 1e12);
    bool(true)

As ridiculous as I think it is, I also take the approach that it's just what PHP does. Weird, maybe a bit eccentric, probably a contributor to difficult-to-find bugs, but it's just something we have to keep in mind. Perhaps I'm feeling charitable because it's Thanksgiving!

[spdionis]

It is well documented that strings are converted to integers when comparing with integers.

It is well documented that when converted to integers, strings containing a number at the start will be converted to that number, and drop any string after, e.g. '1eabc' becomes 1.

It's also been a best practice for a looong time (since something like PHP 5.4) to use === to test for equality.

[Zancarius]

> It is well documented [...]

Yes, it's documented, but it doesn't make it any less obnoxious. IMO the thought of implicit conversion is absolutely asinine.

But, in fairness, PHP isn't the only language that does this. Python, at least, is more sane.

> and drop any string after, e.g. '1eabc' becomes 1.

In defense of PHP, it does yield a NOTICE if you attempt to apply certain operations to implicitly cast strings (e.g. addition), so there's that.

Suffices to say that while I've written PHP for years, I'm quite comfortable with its idiosyncrasies, it doesn't mean I don't find them appallingly brain damaged. :)

FWIW the identity operator (===) is also a best practice in JS for nearly identical reasons which also exhibits similar (and in some cases nearly identical) implicit casting.

[spdionis]

Yes, implicit conversion in both PHP and JS are brain damaged by today standards, but that's life with legacy cruft.

[Zancarius]

> but that's life with legacy cruft.

So true.

I can't really complain. Well, I can, and that's what I've been doing in much of this thread.

It's mostly just yelling at the sky for no good reason other than to make myself feel better at this point, if I were to be completely honest with you.

[jontro]

Still in js "0.2" == "0.20" would always be false. My instinct would be that comparing two different strings would be false in php too.

The problem for me is working with a big legacy codebase. I'd rather have php break backwards compatibility and change === to ==.

[sleavey]

I see. This change prompts me as something that could break a lot of code running on web servers where the sysadmin updates to PHP8 assuming it will be backwards compatible. I wonder if they did any code searching to see how widely used such expressions are in the wild.

[bavell]

I don't think anyone reading the migration guide [0] is going to assume their app/lib is backwards compatible without some effort.

[0] https://www.php.net/manual/en/migration80.php

[rovr138]

And anyone that knows the basics about semver

[scaladev]

And people say C++ is a complicated language.

[will4274]

Yes because ('0' == 32) returning true makes more intuitive sense. There are languages without type coercion for comparisons (e.g. OCaml), but C++ isn't one of them.

[daneel_w]

In the absence of strict type checking it would be terrible, but == performs a loose comparison, and "foobar" cannot cast to any other number than 0. Perl will go about it the exact same way. Contrast this against strict comparison, "0" === 0, which will evaluate as false.

[xeeeeeeeeeeenu]

>Perl will go about it the exact same way.

No, Perl is completely different and IMO it's the only mainstream dynamically typed language that has sane comparison operators.

Perl has two sets of operators, numeric (==, +, *, <, >, <=> etc.) and stringwise (eq, ., lt, gt, cmp etc.). You can think of them as explicit (but concise) casts. For example, Perl's $foo eq $bar is roughly equivalent to Python's str(foo) == str(bar).

It is true that "foobar" == 0 returns true in Perl but, as I showed above, it does that for a completely different reason.

[hypertele-Xii]

Maybe "foobar" should evaluate to NaN.

[_-___________-_]

Does PHP have separate int and float types? NaN is a float value and I would expect 0 to be an int.

[ragnese]

It does