You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue concerns, in the context of Array.p.sort, a comparefn that (at least sometimes) returns NaN or a value that isn't a Number. For brevity, I'll call this a non-numeric comparefn.
In the definition of "consistent comparison function" (CCF), if you call comparefn and get the return value v, then one requirement is Type(v) is Number, and v is not NaN. Thus, a non-numeric comparefn cannot be a CCF, and the resulting sort order is implementation-defined.
On the other hand, we see SortCompare taking steps to ensure that, regardless of what comparefn returns, SortCompare returns a Number, and one that isn't NaN. So you might wonder why it would bother to normalize a case where we already know that the sort order is implementation-defined.
The definition of CCF has excluded non-numeric comparefn since ES 3. But ES 6 (ES 2015) added the steps in SortCompare to handle them. As the last entry in Annex E says:
Previous editions did not specify how a NaN value returned by a comparefn was interpreted by Array.prototype.sort. ECMAScript 2015 specifies that such as value is treated as if +0 was returned from the comparefn. ECMAScript 2015 also specifies that ToNumber is applied to the result returned by a comparefn. In previous editions, the effect of a comparefn result that is not a Number value was implementation-defined. In practice, implementations call ToNumber.
This suggests (fairly strongly) that the point of the changes was to allow the effect of a non-numeric comparefn to not be implementation-defined, and thus that CCF's exclusion of non-numeric comparefn should have been relaxed at the same time.
However, we can't simply drop CCF's requirement that Type(v) is Number, and v is not NaN, because the definition relies on comparing the return value to zero, which is only meaningful if it's a non-NaN Number. Instead I think the definition needs to define a function derived from comparefn (that normalizes its return like SortCompare does), and then express all the definition's requirements on the derived function: comparefn is a CCF if its derived function satisfies all these constraints. (Although, instead of requiringType(v) is Number, and v is not NaN, you can just note that that's always the case for the return value of the derived function.)
The text was updated successfully, but these errors were encountered:
This issue concerns, in the context of
Array.p.sort
, a comparefn that (at least sometimes) returns NaN or a value that isn't a Number. For brevity, I'll call this a non-numeric comparefn.In the definition of "consistent comparison function" (CCF), if you call comparefn and get the return value v, then one requirement is
Type(v) is Number, and v is not NaN
. Thus, a non-numeric comparefn cannot be a CCF, and the resulting sort order is implementation-defined.On the other hand, we see SortCompare taking steps to ensure that, regardless of what comparefn returns, SortCompare returns a Number, and one that isn't NaN. So you might wonder why it would bother to normalize a case where we already know that the sort order is implementation-defined.
The definition of CCF has excluded non-numeric comparefn since ES 3. But ES 6 (ES 2015) added the steps in SortCompare to handle them. As the last entry in Annex E says:
This suggests (fairly strongly) that the point of the changes was to allow the effect of a non-numeric comparefn to not be implementation-defined, and thus that CCF's exclusion of non-numeric comparefn should have been relaxed at the same time.
However, we can't simply drop CCF's requirement that
Type(v) is Number, and v is not NaN
, because the definition relies on comparing the return value to zero, which is only meaningful if it's a non-NaN Number. Instead I think the definition needs to define a function derived from comparefn (that normalizes its return like SortCompare does), and then express all the definition's requirements on the derived function: comparefn is a CCF if its derived function satisfies all these constraints. (Although, instead of requiringType(v) is Number, and v is not NaN
, you can just note that that's always the case for the return value of the derived function.)The text was updated successfully, but these errors were encountered: