nits on BigInt Proposal
d3ck0r at gmail.com
Fri Aug 4 16:10:11 UTC 2017
On Fri, Aug 4, 2017 at 7:52 AM, kai zhu <kaizhu256 at gmail.com> wrote:
> looking at the use-cases for this feature @ https://github.com/tc39/
> proposal-bigint#use-cases, i'm not convinced it improves everyday
> programming, or outweigh the benefit and simplicity having a single number
> 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 https://www.npmjs.com/package/bigint.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss