Temporal has a bunch of nice comparator functions like PlainDate.compare:
myDates.sort(PlainDate.compare);
So convenient!
But oh no, now I need to sort them in descending order instead of ascending:
myDates.sort((a, b) => PlainDate.compare(b, a));
What is this madness?? Did someone make a typo switching the order? Did they forget that you don't need arrow function thunks when passing callbacks? No, they are just doing what they have been forced into by a cold, cruel world. Writing software has become joyless again, mere toil where we strive against the unfathomable machine to exhort our desired results from its CPUs.
But! This tragedy could be fixed by introducing a switch, e.g.
Besides, the meaning of "reverse" is totally obvious regardless of what the comparison function does. "Descending" becomes a misnomer when the comparison function itself defines descending order, e.g. myNames.sortDescending((a, b) => b.length - a.length)
The "right" in reduceRight() has more to do with the original order of the array and which direction you iterate over it. Where sortDescending() does not "iterate" over the items in a defined "order". It requests that the resulting array be in reverse order, however the sorting implementation wants to do that.
Only problem is where to put it. Function.prototype is kind of a weird place though I guess it would work. But I also think we should have some more built-in comparison functions, like the standard numeric one, so maybe a new namespace like Compare? As in, array.sort(Compare.numeric) for ascend sorting by numeric order, array.sort(Compare.reverse(Compare.numeric)) for descending sort.
A Compare namespace would be great for a few other things too, like being able to chain comparisons for tie-breaking, or compare arrays lexicographically, or use a key function on the comparator. I've written that code a few times; it's small and easy, but would be nice to have pre-supplied.