Rules to only allow loose comparison with numeric operands

[jasny]

strictly and strongly typed code with no loose casting for those who want additional safety in extremely defensive programming.

Loose comparison does loose casting with unexpected result. To achieve the purpose of this library, this has to be dealth with.

---

Similar to arithmetic operators (+/-/*///**/%), loose comparison operators should only be used for numeric (and DateTimeInterface) values. This is true for ==, !=, <, >, <=, >= and <=>.

Using any of these operators for non-numeric values may lead to unexpected results.

See issue #40 for more info.

[jasny]

@carusogabriel Please take a look

[jasny]

@ondrejmirtes Fixed and updated. If anything more is needed for this to be merged, please let me know.

[enumag]

<, >, <=, >= and <=> should be allowed for DateTimeInterface values.

[jasny]

@enumag It is; see https://github.com/phpstan/phpstan-strict-rules/pull/41/files#diff-04c6e90faac2675aa89e2176d2eec7d8R12

[ondrejmirtes]

Hi, I tried out this rule and when I get this message:

Only int|float|DateTimeInterface is allowed in ==, null given on the left side.

It's not obvious to the user what they should do instead. So what would probably be better is to center the wording about "you need to use === instead of ==" rather than that something is not allowed...

Can you bring some ideas about the rule positioning and wording with regard to this? Thanks.

[jasny]

@ondrejmirtes I'm happy to change the text. However, I'm unsure about the wording.

The current messages are copied from the existing rules for arithmetic operators and boolean conditions. Do you want something completely different? What is a good example that I might copy?e

Note that what you should do isn't always clear for other operators than == and != (similar to the arithmetic operator rules). What does [object] > 99 mean? I don't know, but it's probably not correct.

[VincentLanglet]

IMHO, the rule should only apply to <, >, <=, >= and <=>.

== and != should be handle (or maybe is already) differently, because === and !== should always be preferred.