Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

operator overloading for a better decimal implementation #19770

Closed
maj-o opened this issue Mar 29, 2017 · 5 comments

Comments

@maj-o
Copy link

commented Mar 29, 2017

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

This comment has been minimized.

Copy link
Member

commented Mar 29, 2017

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.

@bradfitz bradfitz closed this Mar 29, 2017
@griesemer

This comment has been minimized.

Copy link
Contributor

commented Mar 29, 2017

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

@maj-o

This comment has been minimized.

Copy link
Author

commented Apr 3, 2017

@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

This comment has been minimized.

Copy link
Author

commented Sep 5, 2017

(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

This comment has been minimized.

Copy link

commented Sep 1, 2018

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!

@golang golang locked and limited conversation to collaborators Sep 1, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
5 participants
You can’t perform that action at this time.