Array#sort is underspecified

[ljharb]

Reading http://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.sort, I see that the spec says two conflicting things about the compareFn.

Namely, [1, 2].sort(foo), for a non-undefined, non-function foo, both is implementation-defined, and throws a TypeError (the same language is in ES5).

In Safari and Chrome (and IE < 9), a non-function non-undefined argument is ignored, and the default sort is used.
In Firefox, IE >= 9, and Edge, a non-function non-undefined argument throws a TypeError, as I'd expect.

This seems like something we should specify, and that Safari and Chrome should shift to the non-implementation-defined behavior of throwing for a non-function non-undefined argument. Thoughts?

[ljharb]

(The TypeError in the spec is step 4a in http://www.ecma-international.org/ecma-262/6.0/#sec-sortcompare)

[ljharb]

(The TypeError in the spec is step 4a in http://www.ecma-international.org/ecma-262/6.0/#sec-sortcompare)

[bterlson]

I don't think there's a conflict here. For non-function, non-undefined comparefn's, the sort order is implementation defined but the result of the sort function is normatively defined in sec-sortcompare. Safari and Chrome are wrong per spec I believe.

[bterlson]

I don't think there's a conflict here. For non-function, non-undefined comparefn's, the sort order is implementation defined but the result of the sort function is normatively defined in sec-sortcompare. Safari and Chrome are wrong per spec I believe.

[ljharb]

Thanks for clarifying! I'll add a patch to es5-shim and a test to the compat-table.

[ljharb]

Thanks for clarifying! I'll add a patch to es5-shim and a test to the compat-table.

[bterlson]

If this isn't covered in test262 it should be :-P /cc @goyakin

[bterlson]

If this isn't covered in test262 it should be :-P /cc @goyakin