Identity. “A is literally B” instead of “A equals B”. This is necessary here in JS because if A is the string “-1” and B is the integer -1, JS evaluates A==B as true because reasons
because if A is the string “-1” and B is the integer -1, JS evaluates A==B as true because reasons
Interesting. If it were the other way around, I think I would have been fine with it (i.e. == used for comparison with type like any other language and === without type). But as it stands now I would hate it if I had to write in JS (but I don’t so it’s fine).
It’s not that bad, honestly, just something you get used to. When I switch to C++ after a while, I sometimes write === and when I switch back to JS after some time, I occasionally forget to use ===.
In C++ it’s obviously an error and for JS I have my IDE set to warn me about ==. I think I’ve used == in JS (and PHP) intentionally once in the last ~5 years.
Honestly, I think it actually makes some sense this way around. To me, in JS “==” is kinda “is like” while “===” is “is exactly”. Or, put another way, “equals” versus idk, “more-equals”. I mean, “===” is a much stronger check of equivalence than normal “==”, so I think it deserves to be the one with the extra “=”
2 equal signs will coerce the second operand into the type of first operand then do a comparison of it can. so 1 == “1” is true. this leads to strange bugs.
3 equal signs do not do implicit type conversion, cuts down on weird bugs. 1===“1” is false.
It seems it is that way, which is weird. You should always convert to the widest type, meaning string for comparing numbers and strings. I just checked that 1 == "01" is true, which means that “01” gets cast to an integer. And according to the document it might be that for example 1 == "a" would basically be interpreted as 1 === NaN which is false.
var bomb = [] for(var i = 0; i === -1; i++){ bomb.push(i) }what does 3 equals signs do
Identity. “A is literally B” instead of “A equals B”. This is necessary here in JS because if A is the string “-1” and B is the integer -1, JS evaluates A==B as true because reasons
Interesting. If it were the other way around, I think I would have been fine with it (i.e.
==used for comparison with type like any other language and===without type). But as it stands now I would hate it if I had to write in JS (but I don’t so it’s fine).It’s not that bad, honestly, just something you get used to. When I switch to C++ after a while, I sometimes write
===and when I switch back to JS after some time, I occasionally forget to use===.In C++ it’s obviously an error and for JS I have my IDE set to warn me about
==. I think I’ve used==in JS (and PHP) intentionally once in the last ~5 years.Honestly, I think it actually makes some sense this way around. To me, in JS “==” is kinda “is like” while “===” is “is exactly”. Or, put another way, “equals” versus idk, “more-equals”. I mean, “===” is a much stronger check of equivalence than normal “==”, so I think it deserves to be the one with the extra “=”
2 equal signs will coerce the second operand into the type of first operand then do a comparison of it can. so 1 == “1” is true. this leads to strange bugs.
3 equal signs do not do implicit type conversion, cuts down on weird bugs. 1===“1” is false.
edit: it appears to be more complicated than that for double equals and the position of operands don’t matter. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Equality
Doesn’t it widen the types regardless of position? Meaning 1 == “1” will be compared as strings, not numbers.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Equality
mdn goes into it more and it’s way more involved than I thought, looks like order of operand doesn’t matter. see the number to string section
It seems it is that way, which is weird. You should always convert to the widest type, meaning string for comparing numbers and strings. I just checked that
1 == "01"istrue, which means that “01” gets cast to an integer. And according to the document it might be that for example1 == "a"would basically be interpreted as1 === NaNwhich isfalse.wow that seems super useful, thanks