Repository navigation
Comparing arrays doesn't give any error #61889
Description
🔎 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
💻 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.
Activity
RyanCavanaugh commentedon Jun 18, 2025
We've tried to prevent this before, but the problem was that
Date > DateandTypeParam > ThatSameTypeParamare 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 #2361DonaldDuck313 commentedon Jun 19, 2025
What exactly do you mean by
TypeParam? ForDatethe solution could be to whitelist specific types such asDate,number,bigint,string, and possibly others.snarbles2 commentedon Jun 19, 2025
I assume
TypeParammeans a generic type parameter (<T>).If we restricted the comparison operators to a specific set of types, you could constraint your
Tto comparable types but I'm sure you would run into complications with generics somewhere along the way.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.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.
kirkwaiblinger commentedon Jun 19, 2025
Note that this brushes up against some linter discussions as well, and we've approved adding a typescript-eslint rule that would ban this: typescript-eslint/typescript-eslint#5647