V: Operator overloading for built in math types
Operator overloading is bad. It makes code unpredictable.
Mike Acton says that it should only be allowed in very simple cases, like adding vectors. I agree.
I want to make V convenient for gamedev and scientific applications. They use a lot of linear algebra, and res := a.add(b).add(c) is a lot messier than res := a + b + c
The only way to achieve this without introducing operator overloading for everything is to have official math types supported by the language (vec2, vec3, mat4 etc).
What do you think?
medvednikov
All 6 comments
Operator overloading used properly absolutely makes code more readable. Would you like to prevent someone coming along with a numpy or pandas or tensorflow with readable operators for V? You aren't going to build all that into the language. Something to consider.
tjpalmer
on 16 Mar 2019
Operator overloading can be nice, but it's mostly syntactic sugar. It doesn't add much in the way of readability, and despite a.add(b).add(c) being slightly annoying to type, it's clear in its intentions. Go has survived without this feature so far, throughout its tiny lifespan, then again it's not used that often in scientific applications. Anyway, those are my two cents on the matter.
sug0
on 16 Mar 2019
You could as well argue that primitives aren't used often anyway, so why have operators in the language at all? Still, any solution, including built-in vector types, could easily be added after 1.0.
tjpalmer
on 16 Mar 2019
Oh absolutely, this is going to happen after the public release.
medvednikov
on 16 Mar 2019
In my opinion there's absolutely nothing wrong with allowing operator overloading. If people write messy code, they're going to write messy code; and limiting them won't help that.
I've always found the debate about operator overloading absolutely confusing. Yes, people can use the + operator to do something other than addition, and not allowing operator overloading makes that impossible. However, they could also write an .add() function that does something other than addition. Why is the latter a better alternative than the former?
Causeless
on 18 Mar 2019
I needed this today, so I just spent about 20 minutes to implement it:
medvednikov
on 12 May 2019
Related issues
taojy123
路
3Comments
medvednikov
路
3Comments
vtereshkov
路
3Comments
XVilka
路
3Comments
penguindark
路
3Comments
Most helpful comment
In my opinion there's absolutely nothing wrong with allowing operator overloading. If people write messy code, they're going to write messy code; and limiting them won't help that.
I've always found the debate about operator overloading absolutely confusing. Yes, people can use the
+operator to do something other than addition, and not allowing operator overloading makes that impossible. However, they could also write an.add()function that does something other than addition. Why is the latter a better alternative than the former?