Money type

[Ola Fosheim Grøstad]

On Friday, 3 January 2020 at 14:49:34 UTC, Steven Schveighoffer 
wrote:
> It's not a *terrible* idea, but as you accumulate more errors, 
> they will add up.

I actually use base10 on the server, out of convenience and easy 
maintenance, but my point is that you don't have to as long as 
you understand what is going on under the hood.

You won't get more than a cent error and very rarely, even when 
you don't set the rounding mode if you think about how floating 
point works. And one cannot set the rounding mode in JavaScript, 
so that is what you have to deal with. But it depends on what you 
do. Nobody are going to complain that they get one cent less on 
the invoice than in the "web shop pricing estimate".

> In money transactions, most of the time you have a fixed 
> resolution, and everything is rounded at every transaction. So 
> floating point is not necessary.

Ok, so there you have a use case. If you only add then it is no 
problem, but if you do more complex calculations and more complex 
rounding then it becomes tedious and error prone real fast.

When you add various layers of rebates and sales tax and what not 
it can get tricky to be certain that you will stay within a fixed 
bit width.

If the owner of the system is ok with giving a little more rebate 
(like a cent) then fixed point does not look like a good solution.

> I'd much rather do integer. I like the exactness, and with 
> something like checkedInt, you shouldn't have overflow problems.

Well, but how do you know that you have enough bits and how do 
you account for an unknown number of digits at compile time if 
the end user can type in several rebate multipliers? If you get 
an exception you still have a problem...?

In the general case you basically need to use big-int, and then 
you might as well do base 10, IMHO.