microsoft
Comparing arrays doesn't give any error
🔎 Search Terms
Arrays, Compare, Less than, Greater than
🕗 Version & Regression Information
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about arrays and comparisons
⏯ Playground Link
https://www.typescriptlang.org/play/?ts=5.8.3#code/MYewdgzgLgBAhjAvDA2gIjgIzQGhm4HAEzQF0AoUSWTJVDTHYXfZiqiEAGwFMA6LiADmACgQA+ZJgCUQA
💻 Code
const a = [11, 12, 13]
const b = [4, 5]
console.log(a >= b)
🙁 Actual behavior
This compiles without any error, returning a potentially unexpected result at runtime.
🙂 Expected behavior
This should give an error. Maybe something like TS2365 "Operator '>=' cannot be applied to types 'number[]' and 'number[]'".
Additional information about the issue
What this code actually does at runtime is that first it converts the arrays to strings, then compares the resulting strings by alphabetical order. I'm quite sure this is almost never intended/useful.
Anyone coming from languages like Python or C++ would expect the arrays to be compared lexicographically, which isn't the case here. And in my specific case I actually intended to compare the lengths of the array (and simply forgot to write .length), and not getting a compile time error here led to a bug in my program.
We've tried to prevent this before, but the problem was that Date > Date and TypeParam > ThatSameTypeParam are both idiomatic JS that don't have any strong signal from the type side that differentiate them from this case. This is also somewhat related to #2361
What exactly do you mean by TypeParam? For Date the solution could be to whitelist specific types such as Date, number, bigint, string, and possibly others.
I assume TypeParam means a generic type parameter (<T>).
If we restricted the comparison operators to a specific set of types, you could constraint your T to comparable types but I'm sure you would run into complications with generics somewhere along the way.
type ComparableTypes = Date | number | bigint | string;
function RandomSort<T extends ComparableTypes>(T[] array) { /* ... */ }
More flexible might be if typescript honored some kind of comparability brand (you can certainly author your own types that work with > and <). I don't think that's very likely to happen, but I like the idea that you can opt into it (or out of it) with type assertions.
type Complex = Comparable & {
real: number,
imaginary: number,
valueOf: () => number,
};
As far as arrays specifically, I can imagine people writing code that depends upon the comparability or arrays. I wouldn't encourage it, but I can certainly imagine it.
type digit = '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ;
function IsGreaterThan(a: digit[], b: digit[]) {
// actually works (sort of)
return a > b;
}
Note that this brushes up against some linter discussions as well, and we've approved adding a typescript-eslint rule that would ban this: https://github.com/typescript-eslint/typescript-eslint/issues/5647
