Relax typing for equality and order expressions

[anandthakker]

#5840 relaxed the typing for == and !=, making it possible to do:

• ["==", ["get", "x"], 1] without a type annotation for the "get" expression.
• ["==", ["get", "x"], null]

Some ways we could consider further relaxing typing for comparisons:

• Make an analogous change for >, <, etc., allowing (number | string, value), (value, number | string) so that [">", ["get", "x"], 5] is valid.
• Also allow (value, value) for equality and order expressions, so that . e.g. ["==", ["get", "x"], ["get", "y"]] is valid.

[anandthakker]

Make an analogous change for >, <, etc., allowing (number | string, value), (value, number | string) so that [">", ["get", "x"], 5] is valid.

The main question here is what to do when you end up with a type mismatch between the two arguments being compared. Simply evaluating to false, like we do for ==/!=, is more misleading in this case. On the other hand, adding an implicit type assertion, and thus erroring out of the expression when there's a type mismatch, would make the behavior of > inconsistent with ==, which would also be surprising.

[anandthakker]

On the other hand, adding an implicit type assertion, and thus erroring out of the expression when there's a type mismatch, would make the behavior of > inconsistent with ==, which would also be surprising.

This is the option I lean towards: [">", ["get", "x"], 10] gets parsed as [">", ["number", ["get", "x"]], 10].

It's not the same way we handle == comparisons between different types, but I suspect that for ordering operators, the alternative option of just evaluating to false is likely to create more confusion: E.g., I wrote [">", ["get", "x"], 10], so why did my feature with {properties: { x: '100'}} return false?