Napping.Synth.Download@preinheimer @woozle @IceWolf @cptwtf @ramsey @Crell yes, and frankly considering this premises comparing two strings as numerical makes _more_ sense than forcefully casting the string to an int, as it did prior to PHP 8.
But more importantly `==` Vs `===` is a nothing burger. The behaviour of `==` is important because this is the behaviour used with the ordering operators (e.g. `=<`).
And saying "eh just use `===`" kinda misses the point to why it is a problem.
@Girgias @preinheimer @IceWolf @cptwtf @ramsey @Crell
What doesn't make sense to me is that the operator would ever try to do type-conversion when it's comparing the same type on both sides, and where that type already has comparison rules (even for
<and>).Note that when the string-contents are not formatted as a number, all four operators just do what you'd expect (i.e. use string-comparison rules).
That means it must be first attempting to parse the string as a number, and only if that fails does it use string rules.
This seems wasteful of CPU, however trivially, in addition to the unexpected behavior.
...and given that this can cause false-positive matches specifically when looking at the output of a hash-function, I have to wonder if it doesn't also represent a security vulnerability.
Language opinions aside, the manual should at least clarify the point that all 4 operators will first try to compare two strings as numeric before falling back to what you'd expect -- and should probably note conditions under which two differing strings can be evaluated as equal (there are others, though probably more obvious/expected).
@Girgias @preinheimer @IceWolf @cptwtf @ramsey @Crell
What doesn't make sense to me is that the operator would ever try to do type-conversion when it's comparing the same type on both sides, and where that type already has comparison rules (even for
<and>).Note that when the string-contents are not formatted as a number, all four operators just do what you'd expect (i.e. use string-comparison rules).