Deep JavaScript Foundations, v3

Double Equals Corner Cases

Kyle Simpson

Kyle Simpson

You Don't Know JS
Deep JavaScript Foundations, v3

Check out a free preview of the full Deep JavaScript Foundations, v3 course

The "Double Equals Corner Cases" Lesson is part of the full, Deep JavaScript Foundations, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Kyle uses a code example to make the argument that famous corner cases are often pulled from situations unlikely to occur.


Transcript from the "Double Equals Corner Cases" Lesson

>> Kyle Simpson: Some of you have undoubtedly seen the WAT video I referred to multiple times, and one of the famous things in the WAT video was, how could something like an empty array somehow be coercively equal to the negation of itself? And on its surface, the way that problem is constructed, it seems like a clear arguments against JavaScript, and a clear arguments against the double equals.

But this is not as it seems, this is not as it appears, because this construct is a false construct to begin with. You would never, under any circumstances, compare a value to the negation of itself, ever. That's just never gonna happen in the programs. So we went and looked for this artificial scenario that would never happen in real code.

And then said this whole mechanism is broken because one weird corner case doesn't behave sensibly. Under what circumstances would you ever have an array, and then try to compare it to the negation of the array? Negation of any array, not just itself, of any array? That would never sensibly occur, you would never design code like that.

Nevertheless, let's explain how it works. It's gonna use the exact same stuff I already taught you. If I had two arrays, and for some strange reason, I tried to compare one array to the negation of itself.
>> Kyle Simpson: Compare that in your mind to the more appropriate comparison, which is to say, I want to check to see if they're not the same array.

That's the not equals. Those might look like the same thing, but these are entirely different approaches. One is saying I wanna see if it is coercively equal to its negation, and the other one is saying I wanna see if it is not coercively equal. Those are entirely different beasts.

Line 8 is what you would write in code sensibly. Line 4, the WAT video source, essentially, is what you would never write in code. But let's just indulge it for a moment. To explain the algorithm, how are we gonna explain that line four allows it and also line eight allows it?

How is it possible that both of those can be true? Well, here's the algorithm at play. Number one, we start with the workshop one students not, or equal to the negation of the workshop two students. What we have to do is reduce workshop1Students to its value, which is an array, and then negate workshop2Students, workshop2Students is an array which is truthy.

So if we negate it becomes line five, it becomes false, right? Now, we have a non-primitive compared to a primitive. So we need to turn that non-primitive into a primitive. We need to turn the array into a primitive and what does it become? It becomes the empty string.

So now, we have an empty string compared to false. We have two primitives but they are not of the same type. The algorithm prefers that they both become numbers, so this one becomes a number, which it shouldn't. But it does become the number zero instead of nano and this one needs to become a number as well and now zero is equal to zero, okay?

The algorithm is sensibly applied, but it's on a bogus corner case that would never actually happen in your code. So it's not an effective argument against this mechanism. It makes for great videos and great headlines but it is not a rational argument. The second one is much more rational, because if we look at the equivalent of the not equals, it is basically like the negation of the coercive equality.

So we can ask ourselves, does it make sense for workshop one students to be coercively compared to workshop two students? Well, since they're both arrays, then what we're effectively doing is asking an identity question. We're saying, are they not the same identity? Which is a totally valid thing for you to ask in your program.

>> Kyle Simpson: And it would work identically if you use the triple equals version of them. It's a rational thing, and it has no difference in the rational case between double equals and triple equals.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now