Implement method overloading in GDScript

[me2beats]

Describe the project you are working on:
gdscript plugins

Describe the problem or limitation you are having in your project:
I often need to create similar methods that do similar things (and even usually return the same type), but differ in arguments (their number or their types).

The problem is that the more subtle the difference between the two methods, the more difficult it is to come up with a clear and concise names for the methods.
In addition, it is highly likely that in this case the methods will contain unnecessary redundant information that could easily be obtained from the methods signatures.

On the other hand, creating a single method using optional parameters partially solves the problem, but this creates difficulties in further extending the method, forcing to create a confusing code with a large number of if statements, and ultimately degrade the readability and support of the method.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Implementing method overloading in gdscript would solve this problem in most cases

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Perhaps one of the most beautiful illustrations of how convenient method overloading is, is the Color() methods.

Note how method overloading saved the engine developers from having to create methods like
hex2color()
int2color()
etc

so in gdscript, one could declare several methods with the same name but different parameters.
when trying to declare 2 methods with exactly the same signatures, an error would appear:

The function "x" with signature ... already exist in the class

and when calling such an overloaded method, one just needs to choose a suitable signature, that could pop up just like in the case of Color():

If this enhancement will not be used often, can it be worked around with a few lines of script?:
above I indicated 2 workarounds (one is to set appropriate method names and the other is to use "universal" methods - all in one - with optional parameters), this may be acceptable in small projects, but most likely will lead to difficulties in maintaining such code as the project grows

Is there a reason why this should be core and not an add-on in the asset library?:
I think this should be core feature as it's directly related to gdscript

[Xrayez]

I don't know how easy it would be to implement such a feature without making the codebase more complex, but this proposal showcased constructor overloading specifically (in the screenshots).

I know that one can override _init(), but then again there's no core support for this. Like with Color, constructors are registered via C++ and cannot be overridden in GDScript. I know they do not extend Object, but we're talking about method overloading which apply to any data structure: #279.

See also #1522 where linked list and other similar core data structures could have ability to override constructors on the C++ level, currently not possible, or I simply haven't found a way to do so.

[me2beats]

Another good case when method overloading could be useful:
#737 (comment)

[vnen]

The main problem is that this can significantly increase the call dispatch time, since we can't always know what function to call until it's the time to do so. Even if only the number of arguments were considered, this would incur a penalty on all function calls, even those that are not overloaded (which is the majority).

The available overloaded constructors are not the fastest thing either.

I can't think of a way to implement this without this performance penalty, so I prefer to not do it since this isn't strictly needed.

[me2beats]

I can't think of a way to implement this without this performance penalty, so I prefer to not do it since this isn't strictly needed.

Is it possible for performance penalty to happen only for overloaded methods?

[PrinceMerluza]

The main problem is that this can significantly increase the call dispatch time, since we can't always know what function to call until it's the time to do so. Even if only the number of arguments were considered, this would incur a penalty on all function calls, even those that are not overloaded (which is the majority).

How does other languages do it or Is this caused by the dynamic type nature of gdscript?

[vnen]

How does other languages do it or Is this caused by the dynamic type nature of gdscript?

It's not really because of being dynamic. The GDScript characteristic that makes it differ from most other languages is that each script is compiled in complete isolation (and there's no JIT compiler either). So it's pretty much impossible to do this in GDScript without doing it at the moment of the call, since the script is not aware of the whole environment when compiling. Other languages either are aware of the whole environment at once (so they know which functions exist at compile time) or they use JIT to offset the performance penalty (or they don't allow overloading at all).

Static typing is optional and will remain so, and any feature that works with typing but not without it is just asking for user confusion, so I don't intend to allow that.

The overloaded constructors now (on Godot 4.0) just get faster if you use static typing since those can be solved at compile time, otherwise they still go through the slow path of checking arity and argument types. Those are not so bad because they are always known at compile time to be a builtin type constructor, even with dynamic typing, so they don't interfere with regular function calling in general.

OTOH, supporting variadic functions (#1034) is more feasible, so people could use that and manually handle dispatch for overloads. This is so far the only possibility I see.

---

If anyone has a solution I'm all ears, but until then I'll keep this on hold.