Closure-compiler: BigInt support

[infusion]

Hello,

I wanted to ask for plans on supporting the new native primitive type BigInt. Babel, Typescript and particularly V8 now have support for BigInt constants with an n suffix and operator overloading. As I primarily use CC as a bundler, it would be nice to see support for it.

Thanks
Robert

[brad4d]

We plan to add support for it in 2019.

[EatingW]

Internal Google issue b/64388683 is relevant.

[concavelenz]

There are a couple of bits that make this non-trivial:

• enabling BigInt changes type inference.
• enabling BigInt changes optimizations.

Previously, the code could assume that various operators produced "number", where as not it will need to consider the inputs and assume (!bigint|number).

[maierfelix]

Any updates on this?

[brad4d]

We'll have both input and output support for ES_2019 done in the next few weeks.
Then it will be time to start working on the stage 3 proposals of which this is one.
https://github.com/tc39/proposals/blob/master/README.md

[vapier]

BigInt has hit stage4 and will be in ES2020 ...
https://github.com/tc39/proposal-bigint

but doesn't seem like it's in ECMASCRIPT_NEXT yet :/

[brad4d]

FYI, we're currently working on ?? and ?., which we expect will be more generally useful.

[brad4d]

We're actively working on this now and close to adding BigInt definitions into closure-compiler's externs files.

[logidelic]

Just want to point out that the current version of the closure compiler is actually quite dangerous if one has BigInts in their code (and an older language_out conf; see my Edit below). For example, it will _silently_ change code such as:

BigInt(2) ** BigInt(n)

To:

Math.pow(BigInt(2), BigInt(n))

Which is wrong and will break the code (possibly without someone knowing until it's too late)...

Edit: Actually not as bad as I stated above... Setting language_out to ECMASCRIPT_2019 fixes the issue. Still, should probably not be silent about it when specifying a different language_out...

[brad4d]

Thank you @logidelic for pointing out a case I hadn't considered. I've filed an issue for it.

https://github.com/google/closure-compiler/issues/3684

Otherwise, though, this work is essentially done.