Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explanation of first example is wrong #316

Open
salmanarshad2000 opened this issue Sep 1, 2023 · 2 comments
Open

Explanation of first example is wrong #316

salmanarshad2000 opened this issue Sep 1, 2023 · 2 comments

Comments

@salmanarshad2000
Copy link

Explanation of this example is wrong:
https://github.com/denysdovhan/wtfjs#-is-equal-

The abstract equality operator converts both sides to numbers to compare them

This is just wrong. Strings are compared as strings, null compared to undefined is true, to-primitive might return a string instead on number and so on.

Here is how this expression simplifies:

+[] == +![];

First step would be to convert ![] to false because of precedence.

@tidalu
Copy link

tidalu commented Nov 29, 2023

so, overall, your state is absolutely correct , but here is the thing, [] == ![] , for this problem, even though ![] is firstly converted to boolean, there what the author meant is both sides are converted to numbers to be primitive both sides, :: If the types of the two operands are different, JavaScript attempts to convert them to a common type :: but your state is also true

@shyguy1412
Copy link

shyguy1412 commented Jun 24, 2024

This is not entirely correct also. If you are following the specs precisely here is what happens

  1. We compare [] == false. I skip the step ![] because the right hand expression obviously first needs to be evaluated before the comparison starts
  2. The first relevent case is 9, the boolean is coerced to a number. We end up with [] == 0
  3. The next relevant case is 11, comparing an object to a non object. This coerces the object to a primitive by trying these methods in this order: Symbol.toPrimitive, valueOf, toString. A standard array doesnt have a toPrimitive symbol and valueOf just returns the array again. This means its coerced into a string using toString which concatenates all its elements with a comma. Since its empty, this will just be an empty string so we end up with '<empty string>' == 0
  4. After every step we start our cases from the top again so next case is 5, comparing a string to a number. This coerces the string to a number with Number(string) which in the case of an empty string leads us to 0 so now we finally end up with 0 == 0 which is true

So the correct example for this explanation really should be

[] == ![];
[] == false;
[] == 0;
'' == 0;
0 == 0;
true;

I think the coercion to a string is an important step that shouldn't be left out because otherwise the explanation gives off the impression that empty arrays are directly coerced into 0 all the time which is simply not true.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants