Provide shim library / libraries to allow drop-in replacement of MikeMcl's OSS libraries?

[brad4d]

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?

[littledan]

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.

[ljharb]

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?

[brad4d]

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:

1. Decimal gets implemented as part of the ECMAScript spec.
2. There's also a polyfill so people can start using it right away.
3. However, the users of the existing OSS libraries cannot easily migrate to ECMAScript's Decimal, because its behavior and / or API differ too much from the currently-available OSS libraries.
4. As a result, some new projects start using ES Decimal, but the old projects just stay on the original libraries they were on.

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.