How would BigDecimal integrate into the web platform?

[littledan]

In #2, the README mentions HTML serialization and WebPayments. Are there any other Web Platform APIs that would make sense to integrate BigDecimal into?

[littledan]

• HTML serialization would support BigDecimal, just as it supports BigInt, so BigDecimal could be used in postMessage, IndexedDB, etc.
• In WebPayments, the transaction amount is generally represented as a string. Although strings will need to be used forever in JSON contexts, some APIs may also introduce a way to be used with BigDecimal.

[Simran-B]

I just want to point out that JSON as a format supports arbitrary precision for numbers, but most parsers map them to float datatypes and have no options to warn about precision loss.

JSON.parse("0.30000000000000001") // 0.3

An extended parser could parse BigDecimal literals like 0.30000000000000001m as such, and this would actually safe-guard against rounding errors in other parsers, but then the entire JSON would be considered invalid and unusable to those parsers not supporting BigDecimal. A widely supported, round-trippable interchange format is crucial IMO, but having to rely on strings is a workaround at best.

[jessealama]

TLDR Non-integer numbers in HTML are semantically IEEE 754 doubles so there may be some issues with HTML syntax/serialization (at least, potential loss of information/failure of roundtripness).

It seems to me that value sanitization of some elements in HTML may be impacted. I'm thinking mainly of <input> elements whose type is number, but other elements may also be impacted. The HTML5 spec has a definition for the syntax of a valid floating-point number. Similar to JSON, there are no limitations about precision. The HTML spec also specifies how to convert such arbitrary-precision decimal number strings to IEEE 754 double-precision floating-point numbers (see step 15 of the rules for parsing floating-point number values). So it seems to me that we wouldn't be able to work with anything outside the range of IEE 754 double-precision numbers, not without doing some work on the HTML spec. We would have a lossy conversion if we were to, say, set an attribute of an element to a (serialized) big decimal via JS and then try to work with that value (which got silently truncated) further down the line. (This holds regardless of how the Decimal128 vs. BigDecimal discussion gets settled, since both make it possible to go outside double-precision floats.) In particular, if we serialize HTML after tweaking some decimal values in the DOM we may end up losing information.