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 built in math types #21

Closed
medvednikov opened this issue Mar 16, 2019 · 6 comments
Closed

Operator overloading for built in math types #21

medvednikov opened this issue Mar 16, 2019 · 6 comments
Labels
Bug This tag is applied to issues which reports bugs.

Comments

@medvednikov
Copy link
Member

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?

@tjpalmer
Copy link

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.

@sug0
Copy link

sug0 commented Mar 16, 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.

@tjpalmer
Copy link

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.

@medvednikov
Copy link
Member Author

Oh absolutely, this is going to happen after the public release.

@Causeless
Copy link

Causeless commented Mar 18, 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?

@medvednikov
Copy link
Member Author

I needed this today, so I just spent about 20 minutes to implement it:

#204

spaceface777 pushed a commit to spaceface777/v that referenced this issue May 3, 2022
* Update winnt.h

* Add files via upload

* Add files via upload

* Add files via upload

* Update windef.h

* Update kernel32.def
@medvednikov medvednikov added the Bug This tag is applied to issues which reports bugs. label Jul 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug This tag is applied to issues which reports bugs.
Projects
None yet
Development

No branches or pull requests

4 participants