Like I said, I don't care about the language or semantics. If it's such a big problem for you to overlook the way I phrased it initially, I'll rephrase it:
If a stable sort is used by the browser to implement Array.sort in some scenarios, a stable sort should always be used to implement Array.sort. And like I said, the specific problem is that if users fail to test on data sets that straddle both sides of whatever arbitrary boundary the JS implementor picked, they will fail to observe the browser's actual behavior, and failures will only occur in the wild. The threshold at which V8 switches between stable/unstable could change at any time if they decided the performance gains justified potentially breaking a few applications, and then suddenly more developers would be vulnerable to this. -kg On Thu, Jun 13, 2013 at 9:09 AM, Andreas Rossberg <rossb...@google.com>wrote: > On 13 June 2013 17:56, Kevin Gadd <kevin.g...@gmail.com> wrote: > > I don't really care about the precise language or semantics. 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. > > It does not change. Stable is a subset of unstable. And vice versa, > every unstable algorithm returns a stable result for some inputs. > Mark's point is that requiring "always unstable" has no meaning, no > matter what language you chose. > > /Andreas >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
