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

One of the things that @jakobkummerow proposed in https://github.com/littledan/proposal-bigdecimal/issues/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.

Read the README's discussion of staging, value types, and user-defined operator overloading, then review the linked proposal in issue 31. Compare the methods-and-objects approach with built-in operator overloading and document or reach a decision on which model BigDecimal should use.