Array.prototype.sort make compareFn required in lib.d.ts

[NaridaL]

This is a suggestion to change the signature declaration of Array sort in lib.d.ts from

sort(compareFn?: (a: T, b: T) => number): this;

to

sort(this: string[], compareFn?: (a: string, b: string) => number): this;
sort(compareFn: (a: T, b: T) => number): this;

i.e. make compareFn non-optional for non-string arrays. This would result in errors in cases such as

[2, 10].sort() // returns [10, 2], i.e. sorted lexicographically, which is very unintuitive.

While this is strictly speaking a breaking change, it wouldn't be the first time the typings are stricter than the actually definitions.

[zspitz]

Is this part of Typescript's mandate, to make built-in Javascript APIs safer to use?

[DanielRosenwasser]

We've done it in certain locations, like parseInt.

[aluanhaddad]

Seems reasonable. I do the same special casing for string[] when I write a distinct function.

[kitsonk]

As far as the goal part, it feels like goal:

1. Statically identify constructs that are likely to be errors.

Personally, I can't conceive of a situation where this would be the desired functionality. TypeScript already prevents illogical comparisons and several other challenges. While this is slightly higher order, it does feel very much in the spirit of TypeScript. The only downside is that the error message can't provide any additional information as to why it is an error. Of course the JSDoc could provide some information in the overload as to why it is a bad idea.

[NaridaL]

Support seems to be unanimous, if you tag this as Accepting PRs I'll submit one.

[RyanCavanaugh]

@DanielRosenwasser is going to try this and see what breaks

[RyanCavanaugh]

@DanielRosenwasser dooooo iiiittttt break the world go go go