Repository navigation
Support for TC39 "BigInt: Arbitrary precision integers in JavaScript" proposal #15096
Description
Activity
🚲:house:
Why didn't they chooseZfor the literal suffix?Reacted by Will Frew, sandorvasas, Andre Byrne, Jesse Lee, Christoph, CursedFlames and Felipe S. S. Schneider- changed the title
[-]Support for TC39 "Integer: Arbitrary precision integers in JavaScript" proposal[/-][+]Support for TC39 "BigInt: Arbitrary precision integers in JavaScript" proposal[/+]on Jun 2, 2017 Looks like this may be landing in Babel soon:
Initial (WIP) babel PR for this: babel/babel#6015
Looks like the BigInt proposal has also hit stage 3 (tc39/proposal-bigint@1b4c7e6). Would be awesome to see TypeScript support.
Reacted by Tony Arcieri, Ian Copp, recurrence, Jason Morley, Kenneth Brubaker, Bnaya Peretz, Steven, Paulo Cesar, Michał Lytek, Diego Stratta and 3 moreReacted by Tony Arcieri, recurrence, Patricio Palladino, Bnaya Peretz, Gady, Diego Stratta, 牛牛 and NiroPersonally looking forward to getting the feature available - only concern is the ducktape syntax, my hope is that typescript can help keep the syntax clean.
Reacted by Paulo CesarRyan Cavanaugh (@RyanCavanaugh) Mohamed Hegazy (@mhegazy) Andy (Andrewkraft) (@Andy-MS)
Are there plans to started implementing BigInt now that it's Stage 3?Or does it need to land in Edge first?
Reacted by tomtheisenBigInt is implemented in V8, means we will have it in chrome and V8 soon
refs:
https://twitter.com/bmeurer/status/969656997879713792Reacted by Sebastian Langer, Robin Goupil, samrg472, Michał Lytek, logarytm, Tushar Mathur, Franklin Yu, Steven, Reinis Ivanovs, tomtheisen and 8 moreNode 10.4.0 ships with V8 6.7, a flag is no longer needed to be able to use big integers.
Reacted by Franklin Yu, tomtheisen, Steven, Tony Arcieri, Michał Lytek, Linus Unnebäck, William Cantin and Yukai Huangseems have a plan to support it on 3.0
Reacted by StevenWenlu Wang (@Kingwl) Yes, I see it on the roadmap for 3.0 as you said 👍
For others viewing this issue, the roadmap can be found on the wiki here: https://github.com/Microsoft/TypeScript/wiki/Roadmap#30-july-2018
Reacted by Franklin Yu, samrg472, Tony Arcieri and ulrichb19 remaining items
Thanks for this!
What about indexer type ?
This code is valid JS:[1,2,3][1n]
It means that indexer type now has to be allowed as: string | number | bigint
Reacted by Vitor L Cavalcanti[1,2,3][{toString(){return '1'}}]also works. I'm not sure how indexing is specified in the language though, and whether that includesBigInt. If it doesn't, I'm not sure whetherBigIntshould be allowed.Mark Wubben (@novemberborn) You have a more general suggestion.
Currently Array is defined as type accepting only number as index.
Your suggest to extend indexer type beyond number | string | bingint.type Indexer = number | string | bigint | ({ toString(): string|number })
Sorry, I was suggesting that there are other types that work in JavaScript, but for sensible reasons are not supported in TypeScript.
Reacted by Steven, S. B. Tam, Franklin Yu, ExE Boss and dtmrcBigInt is allowed to be index in ES, so there is no question here.
Btw, I think there was no issue about type with toString property as indexer.What about indexer type ?
This code is valid JS:[1,2,3][1n]
It means that indexer type now has to be allowed as: string | number | bigint
We considered this in #25886 and decided against adding
bigintas an index type. See my comment: #25886 (comment). As Mark Wubben (@novemberborn) says, any value can be used as a key in JS because any value can be converted to a string. Really,stringandsymbolare the only true index types.numberis included becauseArrays andTypedArrays are meant to be indexed with numeric indices. Sincenumbercan store a 53-bit unsigned integer, it is sufficient to index anything stored in almost all modern address spaces (e.g. the 48-bit x86-64 address space). There is really no reason to use abigintas a numeric index unless you have a sparse array (in which case an object should be used instead). You can always just convert thebigintto anumberorstring, which would be a valid index type.Reacted by Franklin Yu, Bnaya Peretz, Trotyl Yu, NN, Reinis Ivanovs and Ghabriel NunesThanks.
Good point.It is probably a bit off-topic but I searched some time for a possibility to use BigInt today and came across this project: https://github.com/GoogleChromeLabs/jsbi
It has the same API and there is a babel-transform plugin to remove it eventually.
Integrating JSBI was already discussed in #28756
Merge pull requested
The ECMAScript Technical Committee 39 has put forward a concrete proposal for adding integers to JavaScript:
https://tc39.github.io/proposal-bigint/
The proposal adds a new syntax for integer literals:
Implicit conversions to/from numbers and integers and expressions with mixed operands are expressly disallowed:
Type constructors are provided that wrap at specified widths:
Integer.asUintN(width, Integer): Wrap an Integer between0and2**width-1Integer.asIntN(width, Integer): Wrap an Integer between-2**(width-1)and2**(width-1)-1Integer.parseInt(string[, radix]): Analogous toNumber.parseInt, to parse an Integer from a String in any base.Though not stated in the spec, these constructors should theoretically hint to the VM when it's possible to use a native 64-bit integer type instead of a bignum, and could therefore possibly be used by TypeScript to implement
int64anduint64types in addition to e.g. anintegertype of arbitrary precision.I know people have been asking for integers for quite some time (e.g. #195, #4639), but have been held back by lack of native support of an integer type in JavaScript itself. Now it seems this
proposal is stage 2(scratch that, stage 3!) and has multi-browser vendor backing, so perhaps the prerequisites are finally in place to make integers happen.