Even if stable sorts don't get required, it would make sense to require that a given implementation is either always stable or always not stable. The current situation with V8 seems likely to result in subtly broken software shipping to the web, where it works in testing environments with small amounts of data and then breaks in the wild only on certain browsers and only if you have a certain amount of data. Yuck.
-kg On Thu, Jun 13, 2013 at 6:05 AM, Mathias Bynens <math...@qiwi.be> wrote: > Bumping this old thread since V8 issue #90 ( > https://code.google.com/p/v8/issues/detail?id=90) has been getting lots > of comments lately. > > It appears that unstable sort, while perfectly spec-compliant, doesn’t > match user expectations. It doesn’t help that some browsers/engines _do_ > use a stable sorting algorithm, while others don’t — which surprises people > and occasionally breaks (badly-written, but hey) code. (See the thread I > linked to for examples.) Then, there’s V8, which uses stable sort for small > arrays with 10 or fewer elements, but an unstable sorting algorithm for > larger arrays, causing even more confusion. > > Here’s a test case that tests arrays of varying sizes: > http://ofb.net/~sethml/is-sort-stable.html The results in different > browsers are listed, too. > > IMHO it would be nice if ES would require a stable sorting algorithm: it > would match user expectations, cause fewer issues in existing code, and > improve operability in general. > > What would be the best way to make TC39 consider this change? > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
