Editorial: Give TypedArraySortCompare its own sub-clause

[jmdyck]

(Salvaged from PR #1612.)

(GitHub's diff is not very helpful: most of the apparent diff arises from a change of indentation.)

[bakkot]

You can suppress whitespace-only diffs by appending ?w=1, incidentally.

[claudepache]

You can suppress whitespace-only diffs by appending ?w=1, incidentally.

Or, more visually:

[ljharb]

i like it

[michaelficarra]

Sure, this is fine. I'd prefer to factor out the closed-over aliases to parameters in a future PR. Or possibly use a spec closure?

[jmdyck]

I'd prefer to factor out the closed-over aliases to parameters in a future PR. Or possibly use a spec closure?

(See issue #1884.)

I think it would be easiest to just add them as parameters.

On the other hand, if you want to factor out Array.p.sort and TypedArray.p.sort's commonalities into an abstract operation, then that would be easier if you recast SortCompare and TypedArraySortCompare as abstract closures that capture the extra aliases.

If you're interested in the latter, this PR would just be churn.

[ljharb]

Let’s add them as params right now then :-) the closed-over things are icky - even if we still refactored the two later.

[syg]

+1 to taking them as parameters.

[jmdyck]

One problem with adding _comparefn_ and _buffer_ as parameters to TypedArraySortCompare (and presumably adding _comparefn_ to SortCompare likewise) is that it complicates the specification of the sorting post-condition and also the definition of 'consistent comparison function'. And not just that you need to add arguments to the invocations, but also that the added arguments aren't consistent between TypedArraySortCompare and SortCompare. There are ways to handle that, but I'd really rather not get into that in this PR (especially if #2305 will take care of it).

[michaelficarra]

I'm fine with addressing it in a follow-up. Let's merge this as-is.