Array#sort() implementations not interoperable

Kevin Gadd kevin.gadd at gmail.com
Thu Jun 13 09:21:43 PDT 2013


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 <rossberg at google.com>wrote:

> On 13 June 2013 17:56, Kevin Gadd <kevin.gadd at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130613/e5ac221e/attachment.html>


More information about the es-discuss mailing list