Godot: overloaded functions bindings to gdScript

[toger5]

overloaded functions would be nice for the GDScript api.

how it currently works
If I bind multiple function with the same name and different parameter footprints, I just overwrite the previous binding.

use case example: #8981

[karroffel]

I think that will be very hard as GDScript is dynamically typed.

[toger5]

Okay I see. Very hard or almost impossible (if so you can close it. It would just be a fancy (aka not important) thing to have anyways)

[toger5]

Oh I wasn't even aware that overloaded functions are not supported in gdScript itself (I though just bindings don't work)
And I also wouldn't know how it should work with being dynamically typed.

[raymoo]

You could dispatch based on the arity of the function. You could also make it so that functions can declare the types they take as parameters and dispatch based on that.

[vnen]

An arity check could work, since GDSscript is quite strict about it when calling a function (except for a few built-in functions which accepts any number of arguments).

However, type-checking for the dispatch would likely cause many cases of unexpected behavior. Also, how would you choose if the actual type does not match any of the declarations?

[raymoo]

You could have a "generic" function to fall back to (when it makes sense to have one), or just give an error if nothing matches.

[hubbyist]

If implemented, default behaviour must be to give error about "function name defined but no matching argument list found" I think. Otherwise finding bugs will not be easy.

Since fallback functions are functions anyway trying to supply them by default for each function will make things complex (Which one is the base and which ones are the overrides?), so developer must be responsible to decide if it is acceptable to supply a default (base) function, IMO.

[raymoo]

There is actually only one sensible way to decide which function is the fallback: a function is a fallback of another one if each parameter is either the same type as the non-fallback function, or is an unspecified type. Also at least one parameter that has its type specified in the non-fallback function should be unspecified in the fallback.

You can guarantee that the most specific function will be used if you sort the overloaded functions by number of parameter types and then check each one for a match, starting with the one with the most specified types and ending with the one with the least. A "fallback" function will always have less defined parameter types than the functions it is a fallback for, so will be checked later.

[raymoo]

I spoke too soon actually, I thought of an ambiguous case. If you have func(int, string), both func(unspecified, string) and func(int, unspecified) would be valid fallbacks, and it's ambiguous which should be chosen since neither is a generalization of the other.

[toger5]

How much additional work would it be to add typehints. So dwvelopers can make overloaded fucntions more specific by defining the type of each parameter.
I think errors when no function is found is the best solution.

[kubecz3k]

I'm closing this one since there was no new interest in the discussion for 11 months...
In 3.1 we should have optional static typing, let's see first how it will be implemented and improve from that point.

[aaronfranke]

@vnen Would function overloading be feasible to have in GDScript? Might be worth re-evalutating now that you've done all that work on Typed GDScript and warnings.

[vnen]

@aaronfranke the problem is that typing is optional, so it's not always possible to detect which function to call at compile time. Using a runtime dispatch would be quite bad for performance and could lead to ambiguities as discussed previously. Again, it's feasible if the distinction is only in arity and not in types, but I don't think it's worth it

If it needs to work with bindings as well (which was the original topic), it would need a big change in the core, then it would be even less worthy.