As I have explained, they are not isomorphic, the relationship between miles/yards are immutable universal constants, money is not like that.
Even tough the concept of dollars/hour makes physical sense, you start to get into trouble when you try to convert that to yuan/minute, a critical corner stone of these types of libraries is consistent convertibility, and the ability to define all your conversions at compile-time.
Some fundamental properties are violated when we talk about money:

  1. The already referred problem that conversions are not even compile-time constants, much less universal invariants.
  2. Money relations are not transitive, ex. If you have A dollars = B euros, and B euros = C yuan, A dollars is not necessarily equal to C yuan
  3. It may not even be commutative A dollars -> B euros is not the same as B euros -> A dollars
These types must never be convertible between themselves, and you will always need an exchange facility to define the rules of conversion.

Hope this clarifies.

From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Sent: Thursday, March 14, 2024 7:18 PM
To: sg14_at_[hidden]p.org; Mateusz Pusz <mateusz.pusz_at_[hidden]>
Cc: Tiago Freire <tmiguelf_at_[hidden]>
Subject: Re: [SG14] Next SG14 meeting on April 10th - Low Latency Financial Systems

On Thu, Mar 14, 2024 at 1:48 PM Tiago Freire via SG14 <sg14_at_[hidden]<mailto:sg14_at_[hidden]>> wrote:
> The `Money` class seems isomorphic to Mateusz Pusz (cc'ed)'s work with mp_units. You should look into the state of WG21 proposals around "units library."
It would be interesting to hear from Mateusz (or, I bet, he's written something somewhere already) on the question of whether there are important/insurmountable differences between physical units like "meter" and monetary units like "euro," or whether the same C++ approach can work for both just fine. I can't think of any differences — except that monetary units should never be interconverted without some kind of GetCurrentExchangeRate sigilling — but I also wouldn't be terribly surprised to hear that there were some subtle-but-insurmountable differences in practice.

I can answer that question. Money conversions are not a compile time constant, which is a requirement for mp-units

For GetCurrentExchangeRate, sure, I covered that in the part you quoted.
But there's at least three more parts to mp_units:
- Exact representations of fractional parts, and conversions among those parts. It feels to me as if the relationship between pounds, shillings, and pence (or yuan, jiao, and fen) is exactly isomorphic to the relationship between miles, yards, and inches; but I wonder if I'm missing something subtle.
- Type-safe manipulations; e.g. it should be physically impossible to store a `yards` value into a `miles` variable, let alone into a `liters` variable. It feels as if `pounds` and `yuan` should work the same in this respect, but I wonder if I'm missing something subtle.
- Automatic handling of products and powers; e.g. 1 newton times 1 meter should type-safely produce one newton-meter; 1 newton divided by 1 kilogram should produce 1 m/s^2. It feels as if e.g. "dollars per day" should work the same in this respect, but I wonder if I'm missing something subtle.
- And then there's the unknown unknowns!