89

While JavaScript's type-strict comparison operators (===, !==) are nice, it doesn't have corresponding strict comparisons for greater/less than.

var x = 10;

x <= 20;    // true
x <= '20';    // true
x <== 20;   // true (or would be, if JS had such an operator)
x <== '20'; // false (ditto)

Why not? I ask this question fully expecting the answer to be "uh, because it doesn't", but I'm asking anyway, in case there's an interesting and/or disheartening historical reason for such operators being omitted.

mwcz
  • 8,949
  • 10
  • 42
  • 63
  • 4
    A similar question, about ways to overcome this limitation: http://stackoverflow.com/questions/13091058/best-and-or-shortest-way-to-do-strict-non-type-converting-compari – mwcz Jan 26 '13 at 01:59

5 Answers5

44

I can only guess-

If
a === b is false, then
a !== b is true. always.

But, this implication wouldn't hold for <==

If
x <== 20 is false, we cannot infer the result of x >== 20 because it might have been false due to type check, or the relation check.

I think that's slightly confusing, although there's plenty of things in the language that are much worse (type coercion in general, to name one).

However, I think a strict < or > would behave consistently.

Timo Tijhof
  • 10,032
  • 6
  • 34
  • 48
goat
  • 31,486
  • 7
  • 73
  • 96
  • 19
    This reasoning doesn't hold up to the reality of JavaScript. Try `5 > "hello"` and `5 <= "hello"`. Both are `false`, so the implication doesn't hold anyway. The very problem you suggest already exits even with the coercion. – jpmc26 Sep 09 '15 at 01:56
  • How about throwing an exception if types don't match? – Aykhan Hagverdili Apr 05 '21 at 10:22
31

Since a === b is a shorthand for typeof a == typeof b && a == b, you can use this expansion for inequalities: typeof a == typeof b && a <= b for example.

Niet the Dark Absol
  • 320,036
  • 81
  • 464
  • 592
  • 12
    My question was "why", not "how". See the link I posted for a discussion of "how". – mwcz Jan 26 '13 at 02:03
  • 3
    +1, good explanation! ;) I'd add that === checks for same type of fruit in the basket and that there's no way of determining weather apple >== orange. It's simply not a qualitative comparison. Maybe that answers the 'why' part? – TildalWave Jan 26 '13 at 02:07
  • Is this still correct? because i been reading the documentation and the algorithms for determining equality. It said on their site that `==` uses `===` and not the other way around... E.g. if they are equal type `==` uses `===`. if they are different type then the operands are converted to the same type and then uses `===` again. – Renzhentaxi Baerde Mar 16 '16 at 16:11
  • @user3475902 - It said on *who's* site? [ECMA 262, 6th Edition, 7.2.12](http://www.ecma-international.org/ecma-262/6.0/#sec-abstract-equality-comparison) states that `===` is used if and only if the types of the operands are the same. If the types are not the same, then coercion is attempted. So yes, this answer is still correct in the sense that comparing types is functionally equivalent to the standard for `===` (though it's not quite accurate to call it a "shorthand"). – JDB Jun 03 '16 at 15:35
8

I'm not sure there is an answer to your question. My guess is, the intended use is for comparing numbers to strings (and maybe booleans). It actually works for those cases, as the non-strict equality operator does. Anything else is subject to arbitrary type coercion rules anyway. What would be the "correct" output of [] < {}? false? Maybe undefined? Note that the types don't even need to be different, ({foo: 1}) < {bar : 2} also doesn't make any sense.

In my opinion, they (Brendan Eich, and later the ECMAScript committee) just decided to trust that the developers would only compare things that make sense comparing. Or didn't even consider that developers would try crazy comparisons. Creating extra operators for comparison would only clutter the language. And don't forget comparisons are not the only pitfalls when dealing with type coercion, there's also addition, subtraction, etc. So I guess they just decided to be true to their decision of allowing operations between different types. They thought that would help people when they know what they're doing, but maybe didn't anticipate all the confusion that arose from that.

bfavaretto
  • 71,580
  • 16
  • 111
  • 150
0

To show why it doesn't make sense to have it, consider instead...

var x = 10
var less = (x <= 5)

Now, both

x <== 5

and 

x <== '5'

would be false, but for different reasons. In the first instance, you could use the assumption that x > 5, but not in the latter case. To avoid false assumptions it is better to use === or !== first and then comparison after.

mwcz
  • 8,949
  • 10
  • 42
  • 63
Tor Iver Wilhelmsen
  • 54
  • 7
0

I'd say that the problem is that strict equality can be well defined for different types (not the same type, then not equals), but relational operators can not be well defined for different types.

Assume we define a strict comparator a <== b to be typeof a == typeof b && a <= b. And the same for a >== b. Then we compare a = "3" and b = 3 and the results are a <== b false, a >== b false and a === b false. Congratulations, you just created a paradox!

Such strict comparator would still mess up things like sorting algorithms, or comparing unexpected values. For example:

for (var i; i <== list.count; i++) {
  doStuff(i);
}

Note that the example is mistakenly using list.count instead of list.length, which will just return undefined, which would just return false when compared to i <== undefined, so the for loop would be entirely skipped to the surprise of the programmer.

It would me much better if JavaScript raised an error on list.count for Undefined Property, and also if comparing different types.

That's all I can say, comparing across types should raise an exception, just like any other decent language out there. But it doesn't.

This means, that the actual practical solution is to start using preprocessors, or just say "Oh well" and keep typing JavaScript ¯\_(ツ)_/¯

tothemario
  • 5,851
  • 3
  • 44
  • 39