For JSON serialization, which doesn't support fixed-point precision it does.

Floating-point precision has too many gotchas for being suitable to store Decimal types, especially for the Currency use case.

Surely it does:

  {
    "price": {
      "amount": 1000,
      "decimal_places": 2,
      "currency": "USD"
    }
  }

How is that better than {“amount”: “10.00”} (which also bypasses all potential floating point parsing issues that your or your counterparty’s JSON library might have)?

It is explicit about the fact that that number of decimal places is part of the data.

The semantics for your string “10.00” are complex - is it considered equal to “10”? To “10.000”? To “10.001”?

A user interacting with an API that uses such a string might make all sorts of assumptions about what it supports.

A user interacting with an API that has an explicit decimal places concept is being told ‘decimals matter! They can vary! Here be dragons!’

> The semantics for your string “10.00” are complex - is it considered equal to “10”?

Yes, but "10 USD" would be a non-canonical representation and you probably serialized incorrectly.

> To “10.000”?

Yes, but same caveat as above applies.

> To “10.001”?

Obviously not, and any system you'd ever want to use in a financial context will tell you so.

String and two-field exponent/mantissa representations are mostly the same in terms of semantics, yes. Making it two separate fields makes it less likely it would be put into `parseFloat`, but after doing some research I think strings are more popular in JSON [1, 2], so probably I’d stick to that as well.

[1]: https://msgspec.dev/supported-types#decimal

[2]: e.g. https://getlago.com/docs/api-reference/fees/fee-object#schem..., although they still use `amount_cents` for all currencies as the base rate

It makes a lot of sense if you value correctness over performance.

Unary is exactly as expressive as decimal or binary for integers, but somewhat less efficient, so why would you?

idk, why would you store integers as ASCII strings? It's somewhat less efficient.

Because it's much more explicit. Computers are fast, engineering is expensive. You usually never want to optimize prematurely when dealing with monetary amounts.

Even more explicit would be a PNG of the dollar bills. I suggest that.