operator overloading for a better decimal implementation

[maj-o]

It would be GREAT to have operator overloading like this:

operator (a,b MyType) + (result MyType) {
result = a.Add(b) // just to show what it would do
}

---

This can be used for instance a native or packaged Go decimal type.

res := a + b * (c / d)

is much more readable then

res := a.Add(b.Mult(c.Div(d)))

decimals are hardly needed !
But decimals without operators are unreadable. I can also think of other types like vectors, points, maps and other types like floats or even new types like Number where it also would be great to be able to implement operators. Operators should only be daclarable in the same package or file in which the significant type is declared - so, not overridable.

If somebody wants a comfortable and precise Number type and does not care about performance, this would be easy.

Please, think about it.

Regards,
maj-o

[bradfitz]

We will consider everything, including this, for any future Go 2. Others have had similar thoughts.

If you want to write a formal proposal, see https://github.com/golang/proposal

But I've tagged this LanguageChange so we can find it in the future if/when a Go 2 happens. Thanks.

[griesemer]

@maj-o e.g., see https://github.com/griesemer/dotGo2016 for an implementation of operator methods

[maj-o]

@griesemer : Thank You! YES! Exactly as You presented at dotGo2016!
Intuitive indexing and operator methods would solve many inconveniences.

@Others: you can see it at dotGo 2016 - Robert Griesemer - Prototype your design!

[maj-o]

(I am disappointed, maybe I am the only one - but it's harder for me to read each letter in each line of code then looking for a common syntax - and the problems are getting bigger with the time)

Now we have Go 1.9 with a sync.Map - this is good in the core. But: existing code must be changed and new code invented (for reinitialisation of a map)...

How beautefull and usefull this sync.Map could have been with operator methods.

[hooluupog]

Go 2 draft design happens. I leave my feedback here:
I really like the idea of operator method introduced by Robert Griesemer in dotGo 2016[0]. The math/Big package is a mess without supporting operator method and generics at present. IMO, Generics with proper operator method supporting will significantly enhance Go's ability in Data Science (Gonum will be the biggest beneficiary). In addition, a decent decimal(#issue 12127) library could be introduced into Go with this feature.
There are two flaws in java's generics implementation, type erasure and inconsistency. In java, the '+', '=', and '[]' operators only work for built-in types. When using generics type(user-defined type), i have to use named method for the operations('Add()',' Equal()', 'Array.set()', etc.) It's a pity that i can not use range with a generic container and i can only access it with just ordinary methods but not with syntax like c[k] in Go. The built-in generic types(slice, map) and user-defined generic types should not be treated differently(introducing the unnecessary complexity). We should avoid making the java mistakes again. Keep the language simple and clean.
[0]. dotGo 2016 - Robert Griesemer - Prototype your design!