Take the 2-minute tour ×

I mean it as it is used in JavaScript. Just curious why this is not supported in more languages? Like Java for example does not have it? Seems to be a very useful operator to have.

share|improve this question
Java is a statically typed language, therefore there is no need to check based on type because Java always knows the type at compile time. JavaScript has dynamic typing, thus it is not always known what type an object is in advance, thus the extra operator. –  Stargazer712 May 26 '11 at 20:22
JavaScript's === is just there because == has annoying, counter-intuitive behavior. Languages that don't have a broken == don't need to fix it with a ===. –  Rein Henrichs May 26 '11 at 21:18
@ReinHenrichs - == in JavaScript (or PHP) is not 'broken' - it's just that the dynamic/loose typing allows for 0 == '0'. –  HorusKol May 27 '11 at 1:21
Yes, I understand the behavior. I just think it's terrible. –  Rein Henrichs May 27 '11 at 1:49
Obvious answer: Because in most languages, == means what === means in Javascript. –  user16764 Apr 23 '13 at 18:02

2 Answers 2

up vote 17 down vote accepted

Javascript's and PHP's "regular" == operator does implicit conversions. === exists so you can omit these coercions when you don't need them or don't want them to apply. In many other languages, including dynamic ones (e.g. Python), implicit conversions are vastly less frequent. That is, integers may be converted to floats when doing math or comparing, but "1" won't go along with 1. In those languages, the == operator is basically the equivalent of looser language's ===.

To pick up the example, Java goes even further - its == will only consider two expressions equal if the evaluate to exactly the same reference, i.e. are the same objects (primitive types are, as usual, an exception). You can't get any stricter. What should a === do, consider two references equal only if they resulted from the same expressions? ;-)

share|improve this answer
In C#, it would have been useful to have separate value equality and reference equality operators, rather than having an "==" operator whose behavior sometimes mirrors that of the effectively-virtual Object.Equals and sometimes mirrors that of the non-virtual Object.ReferenceEquals. Consider, for example, given function bool Eq<T>(T p1,T p2) where T:class {return p1==p2;}, what is the effect of bool StrEq(string p1, string p2) {return Eq<string>(p1,p2);}. If the latter function called Eq<object>(p1,p2) it should be expected to use reference equality, but... –  supercat Jul 19 '12 at 15:35
...it will still use reference equality even if it calls Eq<string>(p1,p2), even though the operands to == would appear to be of type string. –  supercat Jul 19 '12 at 15:37
@supercat That's interesting and ugly, and yes, separate operators for value and reference equality is a good idea. But it's not really related to the question, isn't it? I'm not complaining, I just want to be clear about this. –  delnan Jul 20 '12 at 15:43
I was reading the question as asking fundamentally why more languages don't have more than one type of equality-comparison operator; your answer seemed to question why such a thing would be needed in Java. Having an extra operator would be most helpful if code could use it for those types, and only those types, which explicitly define it (the way the = operator works in vb.net, btw). Perhaps Java could have defined a valueEquatable interface, and had one of its equality operators only act on primive value types or types which implement valueEquatable? –  supercat Jul 20 '12 at 16:05

In JavaScript == uses type coercion for evaluating equality.

0 == false //=> true
1 == true  //=> true
null == undefined //=> true

Using === eliminates type coercion, acting as you would expect the operator to act. If the types are the same and the values are the same it returns true, otherwise false.

Other languages that do not utilize type coercion for equality checks don't need a === because that functionality is standard.

share|improve this answer

Your Answer


