J. S. Choi

Since the issue is deployment to production, perhaps “polyfill” in this pull request should be clarified to “experimental polyfill” (even if this is redundant, maximal clarity can be good). The...

I presented a [brief update presentation][] about this issue to the Committee at the October plenary today. @waldemarhorwat expressed continued confusion over other representatives’ opposition to BigInt `sqrt` without specific...

Thanks @waldemarhorwat for your work on a reference JavaScript implementation of BigInt `sqrt` and `cbrt`. (I’ve also removed `clz32` as per a conversation with @syg.) I’ve added back `sqrt` to...

Although I’ve been trying to find compromises that maximize the probability that this functionality will eventually be added to the language, I do agree that introducing BigInt `sqrt` but not...

Thanks for the comments! 😄 > Suppose code was written with the knowledge that the `Math` methods will throw exceptions if given `BigInt` values. > If the implementation of some...

It’s certainly true that support for BigInts and BigInt Math will not reach >99% prevalence for many years, and that BigInt polyfills will be needed for a long time. But...

First, I’d like to express gratitude towards everyone bringing their experience and insight about backwards compatibility, especially from Google Closure Compiler and from JSBI. Your concerns are important issues: thank...

These are great ideas. However, the impression I got from the meeting (the notes should become public in a few days) was that the implementors would prefer if this proposal...

Yes, oops, I did mean @codehag. Also, thanks, Mathias; good to know.

Thanks for the comment, @syg. You’re right—as you said at plenary, the number of BigInt-overloadable Math methods is going to be small. So maybe it would be worth expanding the...