ts2365 allows unsafe comparisons: string | number < string | number

🔎 Search Terms

ts2365
relational comparison
binary operator <
binary operator >
binary operator <=
binary operator >=
TypeScript 5

🕗 Version & Regression Information

• v4.9.5 gave zero errors for this code.
• TS 5.0 added errors for lt1 and lt2 which I subjectively like — they promote more explicit code 👍 — but are actually safe type combinations (#52048, ann).
• however lt3, lt4 and lt5 are dangerous at runtime yet allowed by TS.

⏯ Playground Link

link — Run and see Logs

💻 Code

const show = (a: any, ltResult: boolean, b: any) =>
    `${JSON.stringify(a)}${ltResult ? ' < ' : ' >='}${JSON.stringify(b)}\t`

// These two show TS2365 error on '<' operators (TS 5.2.2),
// but the allowed arg combinations actually always compared numerically:
const lt1 = (a: string | number, b: number         ) => show(a, a < b, b)
const lt2 = (a: number         , b: string | number) => show(a, a < b, b)

// These three TS 5.2.2 does NOT complain, but are unsafe!
// They allow string<string which compares lexicographically AND 
// one string one number which which compare numerically
// https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Less_than#description
const lt3 = (a: string | number, b: string         ) => show(a, a < b, b)
const lt4 = (a: string         , b: string | number) => show(a, a < b, b)
const lt5 = (a: string | number, b: number | string) => show(a, a < b, b)

// Only including calls allowed by argument types:

console.log(`lt1: ${lt1(12, 9)} ${lt1('12', 9)}`)
console.log(`lt2: ${lt2(12, 9)}                 ${lt2(12, '9')}`)
// lt3-5 are 100% TS-clean but mix true/false results depending on run-time types!
console.log(`lt3:                             ${lt3(12, '9')} ${lt3('12', '9')}`)
console.log(`lt4:             ${lt4('12', 9)}                 ${lt4('12', '9')}`)
console.log(`lt5: ${lt5(12, 9)} ${lt5('12', 9)} ${lt5(12, '9')} ${lt5('12', '9')}`)

🙁 Actual behavior

lt1–2 give errors Operator '<' cannot be applied to types 'string | number' and 'number'. and vice versa.
string vs. number comparisons actually convert both sides to number so these consistently compare numerically — Run ⏯️ playground and you'll see Logs consistently say 12 >= 9 here.

lt3-5 examples OTOH give no TS errors but allow a string < string case!
Only when both sides are strings (or convert to primitive as strings, despite number hint), JS does lexicographic string comparison.
You'll see in ⏯️ Logs these return mix of < and >= results, depending on whether they were both strings or at least one number at run-time 💥

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Less_than#description, https://262.ecma-international.org/#sec-islessthan

🙂 Expected behavior

lt3: Operator '<' cannot be applied to types 'string | number' and 'string'.
lt4: Operator '<' cannot be applied to types 'string' and 'string | number'.
lt5: Operator '<' cannot be applied to types 'string | number' and 'string | number'.

Additional information about the issue

I suppose the lt5 case is the most "interesting", because the types on both sides are same, and from type-system perspective they're valid sub-set of types < can handle.
In particular this is what you'd write to allow string < string AND number < number at run time, both being perfectly legit combinations to execute.
BUT lexicographic vs. numeric comparisons are semantically different operations (that just happen to share same operator), and practically always you only want one of these meanings when writing the code.

(cf. #49661 which asked about val + val. The answer there was it's about types not identity, but I'd say the more fundamental answer is you meant either addition OR concatenation.)

I don't know what to say about wider types e.g. any < any 🤷 Same argument applies that you only meant one or the other meaning, but enforcing that would break TS goal of gradual typing.

cc @Andarist @RyanCavanaugh

Reproduce the lt3–lt5 examples in the linked TypeScript Playground and compare them with the existing lt1–lt2 diagnostics. Trace the compiler's relational-comparison checking for union operands, then add coverage for the expected errors and verify that the accepted string-versus-string and number-versus-number cases remain supported.