Hi all,

> 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.

Sure! We have prototyped some simple examples already. For example, this is
what we did with Ari Jort in 15 minutes during a break in Kona:
https://godbolt.org/z/5KrPYdqdn.

> I can answer that question. Money conversions are not a compile time
constant, which is a requirement for mp-units, even if you were to get the
exchange rate from a market (ex.1$ = 0.92€) the value is not accurate, if
you have $5M nobody is going to give you 4.6M€, money doesn’t work like
that. You are going to have to sell it to someone else who wants to buy and
the actual rate is going to be whatever you will manage to get in the
future. And also converting the other way around might be a different rate,
or converting it trough a third coin, and you may need to account
transaction fees, etc...

This actually is not true. In mp-units, you can define various
non-convertible units of the same quantity. See a really simple example
here: https://github.com/mpusz/mp-units/blob/master/example/currency.cpp.

> For it to be practical the types must be unconvertible to each other, and
would require a “exchange facility” to do the conversion depending on what
is acceptable, and that is always going to be application specific.

This is exactly how the example mentioned above works. A user has to
provide a custom conversion function to convert between different
currencies. Such a function may account for a specific point in time, local
regulations, bank interest rates, etc. This is why the library framework
can't provide such conversions by itself, and that is a perfectly fine and
type-safe solution here.

Best

Mat

pt., 15 mar 2024 o 13:59 Ville Voutilainen via SG14 <sg14_at_[hidden]>
napisał(a):

> On Thu, 14 Mar 2024 at 19:34, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> wrote:
> >
> > On Thu, Mar 14, 2024 at 12:35 PM Ville Voutilainen <
> ville.voutilainen_at_[hidden]> wrote:
> >>
> >> On Thu, 14 Mar 2024 at 18:29, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> wrote:
> >> > And there are also two verbose summaries...
> >> >
> >> > (1) P2814R1 "Comparing P1144 with P2786" (15 pages)
> >>
> >> Smashing, that one has a summary at the end.
> >>
> >> What is a user of P1144 expected to do about
> >>
> >> "pmr and allocator aware types will behave in
> >> surprising ways when used in containers and
> >> algorithms" ?
> >
> >
> > The proof is in the pudding! Try to find me a "surprising" behavior of
> allocator-aware types. The complete implementation of P1144, one compiler
> and two standard libraries, is available for perusal.
> > - https://godbolt.org/z/eM8saKe6b
>
> I take that as a suggestion to stop spending time on P1144 and to
> focus all work on P2786 instead.
> I do not have time for reverse-engineering riddles.
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>