Operator '<' ***CAN*** be applied to types 'number | BigInt' and 'number' about typescript HOT 8 OPEN

If it works in JavaScript, tsc should not complain.

I mean.. the entire concept of TypeScript is to prevent things that work in JavaScript.

from typescript.

https://stackoverflow.com/questions/41750390/what-does-all-legal-javascript-is-legal-typescript-mean

How is that relevant in this specific case? As far as I know, (number | bigint) > (number | bigint) has no pitfalls: There are no situations where two inputs fail to compare the way one would expect them to. There also isn't a more explicit way to express this comparison.

from typescript.

Normally this is where I say "Ah actually there's a hidden gotcha here" but there really isn't one. JS actually does this right in every case.

from typescript.

@nmain The point of linking that was simply to point out that, in general, "this code works in JS" is not a motivating argument against TS type errors by itself--it doesn't move the needle at all. You need more justification than that.

That being said, I'm very surprised to find out this comparison is allowed, given that from what I recall the spec authors were very careful to ensure mixing bigints and numbers was a runtime error in most other situations. Heck, even +5n, an explicit conversion, is a runtime error!

from typescript.

If it works in JavaScript, tsc should not complain.

Obligatory link to https://stackoverflow.com/questions/41750390/what-does-all-legal-javascript-is-legal-typescript-mean

from typescript.

The spec explainer goes into detail about the rationale for both comparison operators and unary plus.

from typescript.

The real issue here is that BigInt does not refer to bigint as Number does in the JSDoc type expression. It works fine if you replace it with bigint.

/** 
  * @param {Number|bigint} n
  */
function isLessThanFive(n) {
  return n < 5;
}

https://www.typescriptlang.org/play?useDefineForClassFields=true&target=9&module=1&noImplicitUseStrict=true&ts=5.2.0-beta&filetype=js#code/PQKhAICh3CAEAOBDATkgtuA3gOQK7oBGApigD6ECWA5pQHYAuAvuHdLMJAGZ50DGDSgHs64SgGcAMsXHiAKgAskdAGKUAbsQAUdAJTZ2KYgzwpRogDzgArAG5ITIA

from typescript.

@RyanCavanaugh where's the approximate place in the code where this would need to be changed? Is it something that someone unfamiliar with the codebase is likely to be able to find?

(I mean, it seems simple - find some operator list and add a type to a list of comparable types - but I have no idea how far the rabbit hole might go)

from typescript.