Editorial: Define SortCompare as an Abstract Closure

[nicolo-ribaudo]

This PR is extracted from a PR to the "Change Array by Copy" proposal (tc39/proposal-change-array-by-copy#69). Thanks @ljharb for pointing out that we can bring this improvement independently from that proposal.

The SortCompare AO implicitly receives _comparefn_ from Array.prototype.sort, in a way that looks like a closure (but I don't think that it is, since SortCompare is an AO and not an Abstract Closure defined in the Array.prototype.sort steps). This PR passes _comparefn_ explicitly as a parameter.

I also did the same thing for TypedArraySortCompare, that implicitly receives both _comparefn_ and _buffer_.

[nicolo-ribaudo]

All the next lines are just indented.

[ljharb]

This helps progress on #1884.

[michaelficarra]

Suggested change

	_x_: a Number or BigInt,
	_y_: a Number or BigInt,
	_x_: a Number or a BigInt,
	_y_: a Number or a BigInt,

[bakkot]

This doesn't quite work as written because the spec talks about whether SortCompare is a consistent comparison function, which is a function of two parameters rather than 3.

The approach @jmdyck takes to resolving this in #2305 (which is blocked on, that PR has unintended normative consequences) is to make an abstract closure which captures the relevant parameters, so that we can talk about whether that abstract closure is a consistent comparison function without needing to change that definition. That seems like a good approach to take here while we work on #2305.

[nicolo-ribaudo]

<a name="sec-sortcompare"></a> is so that existing links to the spec with #sec-sortcompare continue working:

• Is that a goal we have?
• Is there a better way to do it?

[acutmore]

I've seen other sections with an oldids attribute, though not sure if that would work in this case.

[bakkot]

Is that a goal we have?

Yes, but only weakly - we try to make old links keep working when we can point to roughly the place, but sometimes we can't and that's fine.

Is there a better way to do it?

oldids on the containing clause is probably the way to go. It won't point to exactly this step, but it's close enough.

[acutmore]

Do we think we could split the difference and still retain the bulk of the steps as a seperate AO, reducing the steps in the abstract closure? That would make it easier to share with toSorted in https://github.com/tc39/proposal-change-array-by-copy.

Alternatively that could be done as part of the change-array-by-copy proposal itself.

[bakkot]

I'm going to close this in favor of #2305, now that that PR has been updated to be strictly editorial. They're basically the same, except the older #2305 also refactors the definition of TypedArray.prototype.sort to be fully specified like other built-ins rather than with weird prose. I'm very sorry about the duplicated work. Please feel free to raise any comments there.

@acutmore: Yes, you could define a new AO (say CompareAsStrings) which is just the current body of the SortCompare abstract closure, and replace the current body of SortCompare with Return ? CompareAsStrings(_x_, _y_, _comparefn_).