Jesse Alama

I think, after the various iterations we've gone through in the last couple of months (e.g., #162 and #158) I believe that we properly handle NaNs now.

Coming in cold to this discussion, but it seems that there aren't any arguments here against the arbitrary-precision approach. The arbitrary precision approach would support options on various operations that...

I like the idea of looking ahead (probably *very* far ahead)! My gut intuition is that if the use of something other than decimal becomes truly widespread, then numbers in...

Just to follow up here with the status quo, as of writing: We'll be rolling with IEEE 754 Decimal128 as the underlying data model for decimals. We were debating for...

I think we can close this issue. We've nailed down quite a lot since 2020 and the current iteration of the proposal is essential complete. References to a polyfill or...

Originally, the earlier iterations of this proposal did indeed aim to add decimals as a new primitive type, with overloading. But in the face of implementor response, we've scaled back...

In other words, the withdrawal of the operator overloading proposal doesn't automatically kill the decimal proposal. They're related, but decimal has evolved to the point where it is no longer...

Agreed! And this is what decimal's `toFixed` will do. Given an integer argument, it will properly round after a certain number of fractional digits. The complete underlying decimal data is...

> > Might it be possible to replace Intl mathematical values altogether with Decimal128 values? > > This may have worked before NFv3 but at this point it would probably...

It seems that this issue has been resolved. Shall we close it?