A string type. As parent says: it completely bypasses the problem. Save the numbers between double quotes and be done with it.

▲ lxgr 5 hours ago | parent | next [-]

Except that now you have a new problem: Opinionated theorists that haven’t been part of a nasty “oh no, we accidentally considered some amounts as 10x/100x/1000x larger/smaller than expected” incident in their career yet…

▲ portly 7 hours ago | parent | prev [-]

Storing numbers as arrays of u8? That doesn't make sense

▲ ivanmontillam 6 hours ago | parent | next [-]

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.

▲ notpushkin 6 hours ago | parent [-]

Surely it does:

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

▲

lxgr 6 hours ago | parent [-]

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)?

▲

jameshart 5 hours ago | parent [-]

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!’

	▲	lxgr 4 hours ago \| parent [-]
		> 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.

▲ lxgr 6 hours ago | parent | prev [-]

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

▲

microgpt 5 hours ago | parent [-]

Why not store them in unary then?

▲

lxgr 5 hours ago | parent [-]

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

▲

microgpt 4 hours ago | parent [-]

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

	▲	lxgr 3 hours ago \| parent [-]
		Because it's much more explicit. Computers are fast, engineering is expensive. You usually never want to optimize prematurely when dealing with monetary amounts.