Should decimals with different precisions be incompatible?

[qzb]

Since there are a lot of issues around storing precision alongside actual value (#11, #12, #13), maybe we should make rules stricter and make decimals with different precisions incompatible:

• creating BigDecimal requires specifying precision: BigDecimal(5, 3) === 5.000m;
• two decimals with different precision are not equal: 1.0m !== 1.00m;
• all arithmetic operators return decimal with the same precision as operands:

  0.7m + 0.3m === 1.0m
  0.7m - 0.3m === 0.4m
  0.7m * 0.3m === 0.2m // rounded from 0.21
  0.7m / 0.3m === 2.3m // rounded from 2.3333...
  

• arithmetic operations on decimals with different precision throw TypeError;
• .toString() preserves trailing zeros.

Pros

• Clear rules for all cases.
• Division works 🎉
• Probably easier to optimize by using Decimal128 for decimals with low-precision, but it's not granted since Decimal128 is a floating point format.
• Precision has to be explicitly specified during deserialization from formats which don't support it.

Cons

• Some operations loose information, even though they can be represented with finite precision.
• Still much more complicated than ditching idea of storing precision altogether (Should BigDecimal always be normalized? #26).

[ljharb]

"Precision has to be explicitly specified" is a con, not a pro.

[littledan]

I'm not really convinced that this is the behavior people want from division. Some new thoughts on the problem space at #29.

[qzb]

I'm closing issue, it's not relevant anymore after merging #29