Because luckily, most browsers currently don't show this behavior. But as I have said several times now, there are a lot of browsers and their implementation is subject to change without us noticing it at all.
Originally Posted by rnd me
And if their implementation crashes as soon as the function can't ever return 0 in case of equal elements, their implementation would still be conform to the ECMAScript specification.
While a browser can choose to implement some portions of .sort however they want, the results of their method must conform to the higher-level specified output.
That's not a good example because it doesn't include the specification dilemma. A better example would be having, say, a function called myFloor whose specification says that it rounds any non-negative real number to the biggest integer that is not bigger than the number. Now, you might be able to use it on negative numbers and, say, get myFloor(-0.2) = 0, which might be what you want. But if implementation changed and would suddenly result in myFloor(-0.2) = -1, then it would be your fault because you have misused the function whose specification only told us what happens on non-negative numbers.
Think of it like parseInt(); [...]
let's assume you are right, and that sometimes a unique value is compared to itself.
"True", but if you read the link I provided, you would've seen that ignoring the zero case can cause a sort algorithm to crash. No matter what you expect the output to be, if the algorithm simply requires a zero case, then it does. Why would ECMAScript even mention the zero case if it was generally irrelevant? They have their reasons and we don't need to care about them, we just have to write our code conform to it.
Instead of zero, it returns, say, 1. So, it moves below itself in the list.
if i have a list, [a,b,c], and i pluck out b and put it after the spot where b was, my array is still [a,b,c].
It does not say that. It's how you interpret it by assuming that elements won't get compared to themselves. Which, once again, I have proven to be false in the general sense.
Checking the spec, we see that it's possible to satisfy the criteria outlined while omitting the zero case, depending upon the input set of elements:
And once more: Yes, it is possible in the case of an element being compared to itself. I'm just gonna repeat this a few times because I have said it multiple times before and you seem to try to ignore it. Once more, read the link I provided.
wait, doesn't that say it has to return zero? No, it actually does not, it says it must return zero if x=y, which on a unique array, is impossible.
These are really gonna be the last times I will say that some sort algorithms and some sort algorithm implementations do compare elements with themselves. Some of them even can't function properly if you don't cover this case. It's all there for you to read, the specification is clear that you need to return 0 in case of equal elements and since algorithms might compare an element to itself, but we don't know the implementation, the only way to be safe is to include the zero case. If you're still going to ignore these facts that you can openly read up on, there really isn't any point in continuing this discussion. You wanted proof, I have provided proof.
Just to make one thing clear one last time: Yes, most implementations in most browsers won't show the "false" behavior. There is no "it's always right" or "it's always wrong". It is subject to change and it might be different for every browser.