Overloading math operators (+, - , < ...) in GDScript 2.0

[rambda]

This isn't particularly useful, because apparently you can define your own math methods, like
func add(other: YourClass) -> YourClass:,
func greater_than(other: YourClass) -> bool:.

Also I don't know if there is any drawback of math operator overloading. I just thought it's convenient to have.

For example, I have my own NumAttribute class to hold any float/int gameplay attribute, with automatic clamping/rounding, signals upon any change, etc., which is good. However, performing math on different NumAttribute feels troublesome. If I could do attr1 + atrr2 by overloading _add, or attr1 > attr2 by overload _greather_than (or _gte), that would be cool.

I'm curious why no one has proposed this in the last few years, do you all think operator overloading is unnecessary?

For reference:

Not overloadable	Overloadable
ML Pico Prolog Smalltalk BASIC C Go Java JavaScript Modula-2 Objective-C Pascal TypeScript Visual Basic	ALGOL 68 Clojure Eiffel Fortran Futhark F# Haskell Io Nim R Raku Scala Seed7 Swift Ada C# C++ Ceylon D Dart FreeBASIC Groovy Java Kotlin Lua MATLAB Object Pascal (Free Pascal, Delphi (since 2005)) PHP (using magic methods, ArrayAccess interface, or Operator extension) Perl Python Ruby Rust Visual Basic .NET

Related to godotengine/godot#23488 (The proposer stated the proposal is only for _str overloading, which was already implemented as _to_string.)

[rambda]

My original proposal was to implement the behavior of instances of the same class performing math operations on each other.
Then it occurred to me that there are many cases where there is a need to do different classes to math operate on each other.
But GDScript does not support method overloading.
If you determine the argument type in the overloaded operator method, such as _add, then you cannot hint the method's return type. It messes up the typing system.
It seems overloading math operators is generally impossible.

[Calinou]

Also I don't know if there is any drawback of math operator overloading. I just thought it's convenient to have.

Operator overloading is a form of hidden control flow, which makes a program harder to read. With operator overeloading, you don't know for certain if using a math operator is going to call a function or not (when you don't know the object's type).

GDScript already has a fair amount of hidden control flow (such as set/get properties), but I think we should avoid adding more.

[vnen]

There are plenty of issues about implementing operator overloading.

First it just makes dynamic dispatch more difficult (for operators). We could add version of (Object, Object) for all operators and let the runtime figure out if there is a proper overload. In the simple way it would just check for a magic method in the first Object and call it if it exists or fail otherwise. But this already has one extra layer of indirection.

This would work only for objects of the same type pretty much, or at least for only one combination of types if both implement the magic method (so A + B calls a method on A and B + A call a method on B which may or may not work the same way). If you want multiple overloads, the simple method wouldn't work.

Since GDScript does not have method overloads (and adding those is an extra complication) a possibility would be to have a registry of all possible overloads. You would have to make sure those are registered early enough. Then (Object, Object) operators would look at this registry to decide if an overload exist. Type-matching can be quite a chore, especially for custom script types (which you likely want to use for this feature), so it's just more overhead for you.

With this method, you would be able to add operator overloads for any pairs of classes, including adding more at runtime. This means that GDScript cannot know at compile time if an operator exists or not, much less what type it could return (since this all dynamic). Therefore it cannot optimize this behavior and can't show any error message in-editor even if the operation will never be valid.

---

All in all, while it's technically not impossible, I don't think the cost is worth the gain. It would be extra effort to add indirections that would be used by a handful of libraries and would remove compile-time validations for everyone, just for the convenience of writing A + B instead of A.add(B).