nits on BigInt Proposal

J Decker d3ck0r at
Fri Aug 4 16:10:11 UTC 2017

On Fri, Aug 4, 2017 at 7:52 AM, kai zhu <kaizhu256 at> wrote:

> looking at the use-cases for this feature @
> proposal-bigint#use-cases, i'm not convinced it improves everyday
> programming, or outweigh the benefit and simplicity having a single number
> type.
> my nits are:
> - will this break or complicate existing/future code that does typeof
> checks for numbers? what are the costs of retooling nodejs mongodb / mysql
> / etc drivers and the apps that use them?

from what I interpret, it's not a number; it's a different type entirely,
and does not interop with existing numbers

> - how will JSON.parse and JSON.stringify deal with BigInt? the mentioned
> use-cases for wire-protocols, guids, timestamps, and fixed-point BigDecimal
> aren’t very useful if it can’t easily be serialized / deserialized across
> db / persistent storage
> Apparently it will tostring and require a reviver.

> - are there actual common algorithmic use-cases in frontend programming or
> nodejs apps that need arithmetic on integers greater than 52-bits? should
> that rather be the domain of webassembly?
it's definitely NOT a webassembly thing, because it's a high level

It would simplify computing large factorials... instead of manually
chunking stuff to 5 decimal digits or 4 hex digits... not that it's much of
a use case...

But; there's already a library for this
Why would this be something to add to the language any more than extending

Regarding currency manipulation; I don't see that as something that is as
useful on the client side as it is on a server side... so it doesn't really
need to be in every javascript implementation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list