Math

[ljharb]

BigInt currently is not usable with the Math methods; this will become a much greater problem as BigInt usage spreads (and is something that can be dealt with by a separate proposal).

I would not be pleased if BigDecimal advanced very far without addressing Math as part of the initial proposal; I think it was a mistake for BigInt to defer this concern.

Thoughts?

[littledan]

I'd be up for changing that as part of this whole package, or as a separate proposal to champion first. Do you or anyone else want to propose concretely what to do?

[ljharb]

I’d be willing to look into championing a separate proposal to add BigInt to Math, with an eye for making BigDecimal neatly fit into it.

[js-choi]

See also the Stage-1 BigInt Math proposal, tc39/proposal-bigint-math#13, tc39/proposal-bigint-math#14, and tc39/proposal-bigint-math#17.

My current understanding is that @sarahghp, the lead champion of the Decimal proposal, supports BigInt Math’s current type-polymorphic approach, although I may be mistaken. I, maybe she, and also some other TC39 representatives plan to discuss this in a future TC39 BigInt Math incubator call.

[sarahghp]

Yes, @js-choi is correct: I'm very interested in type polymorphism for BigInt Math and extending that to Decimal. I look forward to the incubator call.

I do think there's a bit of an open question about how that interacts with some Decimal-only library functions (for instance, Decimal.divide(..), but I also think there are clear conceptual differences that will make it less confusing in practice.