Should BigDecimal use operator overloading and primitives, or methods and objects?

[littledan]

One of the things that @jakobkummerow proposed in #31 was to avoid using new concepts in BigDecimal that aren't present elsewhere in the language. The README already explores staging with respect to value types and user-defined operator overloading, but I believe part of the suggestion in this thread was the opposite: that we not use operator overloading in BigDecimal and instead use methods and objects.

Benefits of methods:

• Complete polyfill is possible today
• Less implementation burden

Benefits of (built-in) operator overloading:

• More ergonomic, which could lead to fewer bugs due to misuse
• Most people I talked to as potential users of BigDecimal sounded excited about the potential to use operators here

"Mental model" complexity could be argued either way: While operator overloading theoretically adds more for people to remember when they see +, that isn't what I heard when I talked to JS programmers about BigInt: They didn't see it as a source of confusion or complexity at all, but rather it just makes use of BigInt easier and closer to how it feels like it "should" work.

[jakobkummerow]

(Not to get involved into the discussion here, just to clarify my point: I think it's uncontentious that a + b is cleaner than a.plus(b); I'm certainly not denying that, and would be quite surprised if anyone thought otherwise. So "potential users sounded excited" is not surprising.

What I'm saying is that methods you can use are better than operators you cannot use. BigInt sets the precedent of what to avoid: it's specified with operators, but only those developers who know that their code will run exclusively on recent V8 versions [or very recent Firefox] can actually use those operators (i.e. de facto only for code that targets recent Node versions). Anyone targeting the web, or all officially supported Node versions, or otherwise an "I want my JavaScript to run everywhere" scenario, only has one option for using BigInts, and that's a library (JSBI or other), which uses functions/methods instead of operators. Transpiling away operators for older browsers is effectively impossible.

My conclusion from this situation is: let's learn from this, and avoid making the same mistake again. Sure a + b looks good in theory, but it's not a realistic strategy if you actually want to use BigDecimals in your code.)

(Edit: the same concern applies to introducing new primitives, as typeof cannot be polyfilled either.)

[littledan]

Personally, I am happy about efforts like JSBI, but I like to design things in TC39 for JS programmers 2-5 years out, once there are implementations broadly distributed. I don't think we have to be so conservative to only add features that are immediately, completely polyfillable, since people still will be using JS when BigInt is rolled out everywhere, and they'll benefit from this more ergonomic syntax.

Anyway, we clearly have different hypotheses here about user value. Maybe we can start collecting feedback from JS programmers about how BigInt is going for them, to get an idea of where we should go next.

[littledan]

@jakobkummerow Ah, sorry, I was mixing together your points with other people in TC39 who have suggested that one-off operator overloading adds complexity to the mental model that we wouldn't have if we added user-defined operator overloading. I'm not claiming that you share this view!