Array#sort() implementations not interoperable

David Bruant bruant.d at
Thu Jun 13 09:50:49 PDT 2013

Le 13/06/2013 17:56, Kevin Gadd a écrit :
> I don't really care about the precise language or semantics.
Maybe you should. In my opinion, that would certainly help having your 
case better understood and heard.

> I just don't want applications to break in the wild because an 
> Array.sort implementation's stability changes based on the number of 
> elements.
A stable sort is just a particular case of an unstable sort. So, if a 
sort is "sometimes unstable", then it is "always unstable". The 
impression of a stability for some cases is just a distraction.

It's also not like if "sort" was confusing like isNaN. "sort" does its job.

> That feels like a much easier problem to solve than the problem of 
> some browsers being unstable and some being stable. This is absolutely 
> the sort of thing that would bite me as a JS dev and will bite every 
> person who uses my compiler to convert an application. Why would they 
> test with both small and large element counts?
They can also read the spec and learn they can't rely on sort stability 
(second sentence of ES5 - !). Specs aren't just for 
implementors. As a web developer, I feel it's a time-consuming yet very 
healthy exercise to read specs to avoid pain later down the road. I 
wouldn't have said that for ES3, but ES5 is decently developer friendly, 
especially with links and all that.

If people are unsatisfied with the language sort function, maybe they 
should pick a different sort function, implement one that fits their 
need, why not.
They can even monkeypatch array#sort!
Why not try a stackoverflow sort [1][2]? Try with "stable sort" ;-)



More information about the es-discuss mailing list