'bigint' is not comparable to 'number' with loose equality #30540

Activity

1. Daniel Rosenwasser (DanielRosenwasser)

   added

   SuggestionAn idea for TypeScriptAn idea for TypeScript

   Awaiting More FeedbackThis means we'd like to hear from more people who would be helped by this featureThis means we'd like to hear from more people who would be helped by this feature

   on Mar 22, 2019
2. Daniel Rosenwasser (DanielRosenwasser)

   changed the title [-]bigin cant == number[/-] [+]'bigint' is not comparable to 'number' with loose equality[/+] on Mar 22, 2019
3. calebsander commented on May 23, 2019

   

   Caleb Sander Mateos (calebsander)

   on May 23, 2019

   Contributor

   More actions

   I agree that the error message This condition will always return 'false' is not strictly correct. But comparing number and bigint values for equality should definitely cause a type-checking error. It is not obvious how to compare a bigint to a number—should they be coerced to numbers or bigints before doing the comparison? It makes sense to me that the compiler requires you to explicitly coerce one of them.

   Number(1n) == 1.2 // false
   1n == BigInt(1.2) // RangeError: The number 1.2 cannot be converted to a BigInt because it is not an integer
   
   Number(BigInt(Number.MAX_SAFE_INTEGER) + 2n) == Number.MAX_SAFE_INTEGER + 2 // true
   BigInt(Number.MAX_SAFE_INTEGER) + 2n == BigInt(Number.MAX_SAFE_INTEGER + 2) // false

   The compiler gives the same warning if you tried to compare strings and numbers:

   // This condition will always return 'false' since the types '"1"' and '1' have no overlap.
   '1' == 1 // true

   The fact that bigints can't be used as indices is intentional. Arrays, strings, TypedArrays, etc. are meant to be indexed with numbers, so the compiler should warn you if you are indexing with a bigint.
   Again, the same is true when strings are used in place of bigints:

   // Element implicitly has an 'any' type because index expression is not of type 'number'.ts(7015)
   ['a', 'b', 'c']['1'] // 'b'

   We discussed adding bigint index signatures and eventually decided against it.
4. BTOdell commented on Jun 8, 2019

   

   Bradley Odell (BTOdell)

   on Jun 8, 2019

   More actions

   Caleb Sander Mateos (@calebsander)
   I just ran into the issue of comparing a string and a number: '0' != 0 // false

   TS2367: This condition will always return 'true' since the types 'string' and '0' have no overlap.

   The double equals operator should be thought of as a function with two any parameters since it doesn't do type equality like the triple equals operator does. Or maybe it's possible to improve the core type definitions by encoding the coercion rules into them?
5. calebsander commented on Jun 8, 2019

   

   Caleb Sander Mateos (calebsander)

   on Jun 8, 2019

   Contributor

   More actions

   I think it's good that the compiler gives an error in this case. In my experience, comparing values of different types is usually a mistake. If not, you can explicitly convert the number to a string or the string to a number. But I agree that the error message is misleading—perhaps for == it should just say "Cannot compare values of type 'string' and type '0'".
6. 2A5F commented on Jun 9, 2019

   

   Package (2A5F)

   on Jun 9, 2019

   Author

   More actions

   Caleb Sander Mateos (@calebsander)
   should be error only when strictly
7. calebsander commented on Jun 9, 2019

   

   Caleb Sander Mateos (calebsander)

   on Jun 9, 2019

   Contributor

   More actions

   There are lots of things which are technically valid JavaScript, but TypeScript rightly warns about them because they are usually not what the programmer meant to write. For example, you can multiply two strings in JS and they will be coerced to numbers, but TypeScript forces you to explicitly coerce them. I think this is reasonable behavior, and == and === should both require their operands to have the same type.
8. getify commented on Mar 6, 2020

   

   Kyle Simpson (getify)

   on Mar 6, 2020

   More actions

   TS may rightly want to error on people using == at all. But... if someone uses == instead of ===, then TS should accurately make its assumptions about what == will do. It appears from this thread (and others) that's not the case. Wanting to throw useful errors is fine, but incorrectly representing how JS works is not.

   IOW, the vastly more common perspective (much to my chagrin) is that devs default to using ===, and that's ESPECIALLY true for those who use type systems like TS. So, if someone is going out of their way to use TS, and they choose a ==, and that's allowed by their linter/settings, then the assumption should be they intended to do that, and that they intended to take advantage of the coercive capabilities of ==.

   👍React with 👍7Reacted by ExE Boss, Bruno Fantauzzi, Artur Klesun, Bradley Odell, Ted Newman, Trevor Paley and Eric Lavault
9. abacabadabacaba commented on Dec 1, 2020

   

   Evgeny Kapun (abacabadabacaba)

   on Dec 1, 2020

   More actions

   The interesting thing about comparing numbers with bigints in JavaScript is that it is not implemented by coercing both operands to numbers, nor is it implemented by coercing both arguments to bigints. Instead, the exact real values are compared. Here are some examples:

   These values are different:

   > 10n**50n == 10**50
   false

   But they become equal when coerced to numbers:

   > Number(10n**50n) == Number(10**50)
   true

   These values can be compared:

   > 1n == 1.5
   false

   But cannot be coerced to bigints:

   > BigInt(1n) == BigInt(1.5)
   Uncaught:
   RangeError: The number 1.5 cannot be converted to a BigInt because it is not an integer

   Currently, it is not possible to get this comparison semantics in TypeScript without using type assertions. I agree that == operator shouldn't have the same strict type checking rules as === operator, as the use of the former signals the intent that the operands may be of different types.

   👍React with 👍5Reacted by ExE Boss, Artur Klesun, Michal Srb, Piotr Fusik and Eric Lavault
10. pfusik commented on Feb 6, 2023

    

    Piotr Fusik (pfusik)

    on Feb 6, 2023

    More actions

    This error makes sense for ===, but not for ==. As Evgeny Kapun (@abacabadabacaba) explained, there is no easy workaround of casting operands to number or bigint.

    Please fix it.
11. kirkwaiblinger commented on Dec 24, 2024

    

    Kirk Waiblinger (kirkwaiblinger)

    on Dec 24, 2024

    More actions

    Currently, it is not possible to get this comparison semantics in TypeScript without using type assertions.

    I believe (but could be wrong) that the following replicates the == behavior

    function compare(n: number, bi: bigint): boolean {
      return Number.isInteger(n) && BigInt(n) === bi;
    }

    Note that it's not clear that that's such a useful operation, since BigInts' reason for existing is to handle values outside of the safe integer range, and there be dragons there (as noted in #30540 (comment)):

    Number.MAX_SAFE_INTEGER + 2 == BigInt(Number.MAX_SAFE_INTEGER) + 2n; // false
    Number.MAX_SAFE_INTEGER + 1.5 == BigInt(Number.MAX_SAFE_INTEGER) + 1n; // true

    Therefore, it may well in practice be inappropriate to compare using the == behavior; instead, one of the following may be preferable:

    function compare(n: number, bi: bigint): boolean {
      return Number.isSafeInteger(n) && BigInt(n) === bi;
    }
    
    function compare(n: number, bi: bigint): boolean {
      if (!Number.isSafeInteger(n)) {
        throw new Error("attempted to compare unsafe number with bigint");
      } 
      return BigInt(n) === bi;
    }

    Providing this info not particularly to weigh in on whether the == should be allowed here in TS, but as a reference for some relevant info on the topic that hasn't been brought up in this thread yet, and may be helpful to others like me who stumble upon this issue.
12. kevincox commented on Dec 24, 2024

    

    Kevin Cox (kevincox)

    on Dec 24, 2024

    Last edited by kevincox

    More actions

    Note that it's not clear that that's such a useful operation,

    I don't think I agree. The problem in this example isn't at all related to BigInt or the comparison, it is just that you are leaving the range of a Number. That is a questionable thing to do whether or not BigInt is involved. By that argument you can say that === should be banned on numbers because Number.MAX_SAFE_INTEGER + 1.5 === Number.MAX_SAFE_INTEGER + 1.
13. kirkwaiblinger commented on Dec 24, 2024

    

    Kirk Waiblinger (kirkwaiblinger)

    on Dec 24, 2024

    More actions

    By that argument you can say that === should be banned on numbers because Number.MAX_SAFE_INTEGER + 1.5 === Number.MAX_SAFE_INTEGER + 1.

    This isn't that preposterous a conclusion 🙂! In most programming languages we do avoid exact equality comparison between floats, and use a separate integer type (or multiple) for integer operations.

    It's just in JS, as far as I'm aware, where it's canonical to use the mantissa of floats to represent exact integers, and so we make a habit of performing integer-like operations on floats.

    ---

    Anyways, the important points I was trying to make were simply:

    1. You can replicate the == behavior without using the == operator or a type assertion

    2. But please use that with caution depending on your specific context. Don't blame me if it was a bad idea for your use case 🫶

    👍React with 👍1Reacted by Ricardo Fernández Serrata