The short answer is that your language needs === when it fucked up the semantics of ==, but it's also too popular and you can't fix it without breaking half the web.
Or when it is something like Prolog, where equality is inherently a messy and complex concept.
It's like the ==, but there's one more =
JS's == has some gotchas and you almost never want to use it. So === is what == should have been.
It isn't that insane. But some invariants that you may expect don't hold.
"" == 0
"0" == 0
"" != "0"
One neat feature is you can compare to both null and undefined at the same time, without other falsey values giving false positives. Although that's not necessary as often now that we have nullish coalescing and optional chaining.
I just tested and Terser will convert v === null || v === undefined to null==v. Personally I would prefer to read the code that explicitly shows that it is checking for both and let my minifier/optimizer worry about generating compact code.
Try changing to const === variable. That’s most likely what’s it doing to minimize the risk of accidental assignment.
Wut? This is an automated optimizer. It is not worried about accidental assignment.
I agree it shouldn’t. But I’ve seen linters that automatically change it since they seem to be forcing practical conventions sometimes.
Linters and minifers are completely different tools.
Good point. That’s what I get for shooting from the hip.
Thanks!
It's also important if you're checking hashes (at least, it was - if you're using correct hashing algorithm that isn't ancient, you will not have this problem).
Because if you take for example "0e462097431906509019562988736854" (which is md5("240610708"), but also applicable to most other hashing algorithms that hash to a hex string), if("0e462097431906509019562988736854" == 0) is true. So any other data that hashes to any variantion of "0e[1-9]+" will pass the check, for example:
I did use md5 as an example because the strings are pretty short, but it's applicable to a whole lot of other hashes. And the problem is that if you use one of the strings that hash to a magic hash in a vulnerable site, it will pass the password check for any user who's password also hashes to a magic hash. There's not really a high chance of that happening, but there's still a lot of hashes that do hash to it.
that is terrifying
If you're checking passwords, you should be using constant time string checking, anyway.
More likely, you should let your bcrypt library do it for you.
== but for JavaScript. What you don't understand is the == of JavaScript.
The other comments explains it in pretty good detail, but when I was learning my teacher explained it sort of like a mnemonic.
1 + 1 = 2 is read "one plus one equals two"
1 + 1 == 2 is read "one plus one is equal to two"
1 + 1 === 2 is read "one plus one is really equal to two"
And you hit the nail on the head, is that === is type explicit while == is implicit.
I'd use something like:
= becomes
== equals
=== is identical to
It's funny how everyone thinks "equals" in this context should be "identical to" when, in normal language, it doesn't really mean that at all!
Like == but more strict. The == operator will do type conversion, so 0 == '' will actually be true, as an example. Sometimes (honestly, most times) you may want to compare more strictly.
eight equals equals equals equals equals equals equals equals equals capital d tilde tilde
it depends on what your definition of is is
it depends on what your definition of is is
parseInt(0.00000000005)
5
classic
As a backend developer i still dont know a shit what that means
In javascript, === does not perform type coercion when checking for equality
Because in JS:
1 == "1" // true
1 === "1" // false
Mathematica also has an === operator. And :=.
It's also very language specific, like Pascal/Delphi also have ":=" for assignments and "=" for comparison, etc
That makes much more sense than the other way.
What does the walrus operator do?
I think it's called 'delayed assignment'. So it is almost like =, but you can use arguments to define functions, f[a_]:=a+2.
==== when
== same (after magic)
=== same and same type (in Javascript)
==== same and same type and same actual type (in the backend before conversion to JSON)
===== same and same type and same actual type and same desired type (what the customer wanted)
Lol
Lolololol
Don't forget that _.isFinite('1') returns true ;)
1 + false ? (I have no idea in which order JS would evaluate things as I rarely have to touch that language much anymore)
I'm JavaScript developer.
I love coding WebApps.
JS sucks💩.
https://programming.dev/post/7789832
I still don't understand the
===
operatorEdit: I think a more type strict
==
? Pretty sure I understand the point of typescript now.So in JavaScript there’s the assignment
and the comparator is
Since there’s no types JS will do implicit conversion before comparison when using == in a case like this
But with === it doesn’t. It means literally compare these
But this, however, will
(from node REPL)
Basically it's the real equals sign![perfection](https://lemy.lol/pictrs/image/542c073c-e2ff-4031-afe6-2b1f6f1ab5cf.jpeg)
The short answer is that your language needs === when it fucked up the semantics of ==, but it's also too popular and you can't fix it without breaking half the web.
Or when it is something like Prolog, where equality is inherently a messy and complex concept.
It's like the ==, but there's one more =
JS's
==
has some gotchas and you almost never want to use it. So===
is what==
should have been.All examples are true:
It isn't that insane. But some invariants that you may expect don't hold.
One neat feature is you can compare to both null and undefined at the same time, without other falsey values giving false positives. Although that's not necessary as often now that we have nullish coalescing and optional chaining.
I just tested and Terser will convert
v === null || v === undefined
tonull==v
. Personally I would prefer to read the code that explicitly shows that it is checking for both and let my minifier/optimizer worry about generating compact code.Try changing to const === variable. That’s most likely what’s it doing to minimize the risk of accidental assignment.
Wut? This is an automated optimizer. It is not worried about accidental assignment.
I agree it shouldn’t. But I’ve seen linters that automatically change it since they seem to be forcing practical conventions sometimes.
Linters and minifers are completely different tools.
Good point. That’s what I get for shooting from the hip.
Thanks!
It's also important if you're checking hashes (at least, it was - if you're using correct hashing algorithm that isn't ancient, you will not have this problem).
Because if you take for example "0e462097431906509019562988736854" (which is md5("240610708"), but also applicable to most other hashing algorithms that hash to a hex string), if("0e462097431906509019562988736854" == 0) is true. So any other data that hashes to any variantion of "0e[1-9]+" will pass the check, for example:
I did use md5 as an example because the strings are pretty short, but it's applicable to a whole lot of other hashes. And the problem is that if you use one of the strings that hash to a magic hash in a vulnerable site, it will pass the password check for any user who's password also hashes to a magic hash. There's not really a high chance of that happening, but there's still a lot of hashes that do hash to it.
that is terrifying
If you're checking passwords, you should be using constant time string checking, anyway.
More likely, you should let your bcrypt library do it for you.
==
but for JavaScript. What you don't understand is the==
of JavaScript.The other comments explains it in pretty good detail, but when I was learning my teacher explained it sort of like a mnemonic.
1 + 1 = 2 is read "one plus one equals two"
1 + 1 == 2 is read "one plus one is equal to two"
1 + 1 === 2 is read "one plus one is really equal to two"
And you hit the nail on the head, is that === is type explicit while == is implicit.
I'd use something like:
= becomes
== equals
=== is identical to
It's funny how everyone thinks "equals" in this context should be "identical to" when, in normal language, it doesn't really mean that at all!
Like
==
but more strict. The==
operator will do type conversion, so0 == ''
will actually be true, as an example. Sometimes (honestly, most times) you may want to compare more strictly.See this StackOverflow answer: https://stackoverflow.com/questions/359494/which-equals-operator-vs-should-be-used-in-javascript-comparisons
You don't need Typescript, you need an linter (eslint).
===
is your basic equality like most languages.==
will implicitly cast type.The breakdown is here: https://262.ecma-international.org/5.1/#sec-11.9.3
Modern JS says to never use
==
unless you're comparing againstnull
orundefined
.JS devs should have a font that turns == into ≈.
I wish the assignment operator wasn’t the equal sign.
Ok deal, but that means we need to change the equality operator to 👉👈
You sonnofabitch I'm in!:-P
the pew pew principle /s
Interpreter: Wait, x is 5?
This code: Always has been.
It is now, if you know what's good for you.
:=
That’s delayed assignment.
procrastination assignment
In Haskell, it's the same as the mathematical
=
symbol.cries in PHP
I also came to represent my php breathren.
ChatGpt: 1+1≈2
Reddit: 1+1=your muther (sic, x2)
X: 1+1≈we should violently overthrow the government
4chan: nvm, I don't want to get banned for saying this one
4chan: "Gamer words"
No, that's Discord 🙃
1+1====2!
← dreamberd developerBasically Java in a nutshell
eight equals equals equals equals equals equals equals equals equals capital d tilde tilde
it depends on what your definition of is is
it depends on what your definition of is is
parseInt(0.00000000005)
classic
As a backend developer i still dont know a shit what that means
In javascript, === does not perform type coercion when checking for equality
Because in JS:
Mathematica also has an
===
operator. And:=
.It's also very language specific, like Pascal/Delphi also have ":=" for assignments and "=" for comparison, etc
That makes much more sense than the other way.
What does the walrus operator do?
I think it's called 'delayed assignment'. So it is almost like
=
, but you can use arguments to define functions,f[a_]:=a+2
.====
whenLol
Lolololol
Don't forget that
_.isFinite('1')
returns true ;)1 + false ? (I have no idea in which order JS would evaluate things as I rarely have to touch that language much anymore)
I'm JavaScript developer. I love coding WebApps. JS sucks💩.
Any Verilog devs?