Open brad4d opened 3 weeks ago
I'm not sure if this is possible, if we wanted strict compatibility. Those libraries had certain kinds of customizability, and generally didn't match IEEE Decimal128 semantics. That's why the polyfill had to be a from-scratch implementation rather than a wrapper in the other direction.
It would seem prudent for a production-ready library that quietly matches the proposal’s semantics to get some usage in the ecosystem - if this is what people want, in object form, then surely they’d migrate from existing solutions to this one?
Perhaps I'm exhibiting the X-Y problem in my initial request on this issue. I'll try to state more clearly my specific concerns.
I want to avoid this possible situation:
Now, if it can be demonstrated that those existing OSS libraries could be updated to use ES Decimal underneath, then this problem is certainly avoided. Perhaps there are also other ways.
One concern I have, and which I've heard others express in plenary, is that maybe there isn't a clear "best practice" sort of solution for how Decimal should be implemented that will work for most use cases.
I believe the presentation just given at TC39 session 101 was trying to address this concern by making the claim that the existing OSS libraries differ from each other in fairly minor ways and that the customization features they have are infrequently used.
So, I think I'm also asking for further confirmation that this is, in fact, the case, in the form of a proof-of-concept implementation of some kind.
I'd like to avoid the possibility of this proposal going through, but then we discover that it cannot easily be used to replace the existing OSS libraries.
Would it be reasonable to create one or more shim libraries that allow the Node.js library to be used as a drop-in replacement for the existing OSS libraries?