We do a lot of calculations on currency values - calculating income taxes, bills, ... As You all know, float in any kind, does not work. (for those, who don't know that there is a problem: There are problems with float-types and there are problems without decimal type(s) - for instance this: https://groups.google.com/forum/#!topic/golang-nuts/SfdApDgi4i8 ).
This is why there are so many implementations of a decimal type in different go packages. With all this packages and the build in types You can save Your decimal values to databases - one small step! But You can do nothing else. In Go there will be no serious calculations with decimals or any other not build in type. Because You have no operands for values of this types, You have to user Methods like Add, Mult and so on. This a No Go for uge calculations on (for instance) decimals.
We have realy a lot of currency calcualtions (each year new formulars for taxes and insurances) - there is no way using decimals for this, because it's actually not readable. So we use decimals in database and float64 for calculations, though knowing that the calculated results are wrong and we have to convert the values twice. On some places we use our own round functions, because checking if a value is greater than a border with float valuas is like throwing dice. So we have to much code, workarounds and hidden errors - but we have also readable code for komplex formulars - and this is important - it's convinient for reviews and changes.
Thoughts
My first thought has been, that Go is missing decimals, like it has complex numbers. Maybe, but there are other calculations with other types - and it would be much easier, if each type could have its own Operator implementations. If the assignment operator would also be a method - this would be perfect.
Some people fear the misuse of operator methods. If this is the point: You as developer have the choice which package You use and how You implement something. If You don't like it, don't use it. I don't fear it, because it would just impact a type declared in the same package - so operator methods can not do harm.
There are so many workarounds on github trying to make decimals usable. I'd like to have the choice and use one decimal implementation where complex formulars are quickly readable and their results correct. For small calculations, like in an online shop system, it may be just convinience. For us it's realy importartant.
Target features to cover any type:
- to be able to apply standard operators on any types, if this operators are defined
- and to be able to define operators for any types
Example:
// operator method for decimal addition
func (a decimal) + (b decimal) decimal {
return a.Add(b)
}
possible usage:
var a decimal
var b decimal
...
c := a + b
The solution has been implemented and presented by Mr. Griesemer: https://www.youtube.com/watch?v=vLxX3yZmw5Q
Perfect for linear algebra, taxes, bills, and any other problem where operands make common sense.
Well, I am not a great (text) writer - I just want this topic not to be forgotten, if somebody thinks about Go 2
While I love the power available in being able to define operators for types upon which these operations make sense… all too often, these get used for “overly creatively“ solutions to problems that it should probably not be applied to.
The biggest example of this is perhaps the “cout” and “cin” and operator overloading given in the C++ stdlib. Arguably, the decoration is nice, but it fundamentally breaks away from the semantics of the operators which they use.
Linear algebra, and currencies and many mathematical types carry semantically analogous mathematical operators. But opening up operator redefinition opens up the ability to fundamentally break the semantics behind operators.