Allow to call a Callable with ()

[me2beats]

In GDScript 2.0 (Godot 4) you can write so

func f():
	print(1)

func _ready():
	var f_call = f
	f_call.call()

Can we write simply f_call() ?

[vnen]

I had considered this before, but there are technical hurdles that stop us from doing it that way. Essentially, there's no way to know at compile time if it's a Callable or not and to test that at runtime would incur in a performance hit for all calls (Callable or not).

[xix-xeaon]

Could you explain the limitation more clearly? I assume you mean you can't differentiate between a "Callable" and a "real" function. But why should these be different things? I don't know how it's implemented but if one writes var f_call = f then I would think f_call should just point to the same memory, in the same way, as f does. Writing f_call() would do exactly the same as f() - no need to differentiate because they're equivalent. Why does it need to become a "Callable" all of a sudden just because you assigned it to a new name?

If you can figure out a solution then many people will be happy =)

[dalexeev]

I could be wrong, but the problem is probably that it's impossible to determine in advance whether f in the object.f() syntax is the name of a method or the name of a property containing a Callable. As far as I know, in 4.0 it is forbidden to have properties and methods with the same name, but apparently this is not enough to avoid overhead checks.

[vnen]

I could be wrong, but the problem is probably that it's impossible to determine in advance whether f in the object.f() syntax is the name of a method or the name of a property containing a Callable

Yes, this is the problem.

As far as I know, in 4.0 it is forbidden to have properties and methods with the same name, but apparently this is not enough to avoid overhead checks.

At compile time there's not enough information to determine that. We can't even tell if the name is actually something in the object. With static typing it is possible, but this is optional in GDScript so it's not always present.

The main thing is that Callables do not exist unless explicit created. So with var f_call = f you are actually creating a Callable that will reference to the f method in the current instance (self). It's the the same as var f_call = Callable(self, &"f").

Also, Callable is not the same thing as a function pointer (as it also references the object instance) and there isn't really a concept of "function pointer" in GDScript. Essentially they are different concepts. To call a function requires a different instruction (in the GDScript VM) than one to call a Callable.

To illustrate, when you call a function the VM under the hood calls something like: obj->call(method_name, args...). This will look up the method name in the hash tables where it could be found (the script or the native engine class for instance). Which will turn into a GDSciptFunction (the underlying compiled GDScript code) or a MethodBind (a native method). So when compiling, we take f() and obj.f() and make it a call instruction.

Now, if f turned out to be a Callable, that instruction won't work because the name f isn't on the list of methods of the object, neither script nor native, so the call just fails. To properly call it, we would need to know f isn't a function and then get the name as a property, which will give us a Callable, then use callable.call() under the hood.

A way to make this work would be to always get the name as property, which would give a Callable in return even if it is a method. But that involves creating a Callable in the first place and that is not free. It would hinder all function calls so it's not worth it.

[ryanabx]

A way to make this work would be to always get the name as property, which would give a Callable in return even if it is a method. But that involves creating a Callable in the first place and that is not free. It would hinder all function calls so it's not worth it.

What if the reverse were done? Where we assume first it's a named method, and if the method doesn't exist the property list is checked for a named callable?

Edit: this would introduce a precedence for functions if a callable property and function are named the same thing and you use name() instead of name.call(), but I'm not sure if that's allowed anyways.

In this case, all failed function calls will check for a callable property of the same name.

[theraot]

I think we can break this by cases:

• If the parser knows it is a callable via static typing, then calling a Callable with () could be supported.
• If it is on the same object, presumably the parser can check the script and parent classes for a method, and if it isn't, have () emit the code for .call().
• If it is on another object - and it cannot be determined if it is a Callable - then calling could use an execution pathway that first tries to get a method to call, but if it isn't a method, it tries to call as a Callable (as suggested above).

I think the first one would be good. I'm not sure about the second case. But I'm not convinced the third case is desirable (It would mean that on not statically typed code calling a Callable with () is slower than with .call()).

[vnen]

What if the reverse were done? Where we assume first it's a named method, and if the method doesn't exist the property list is checked for a named callable?

I did consider this at the time when I rewriting the parser, but now I don't remember exactly why I didn't go with this.

Do note that is not only properties, since you can have constants or local variables. It might be feasible if the compiler inserted the identifier's address to use its value as a fallback. But this also incur in some penalty to all (dynamic) calls, because even after a successful call there'll be a need to check if the call was indeed successful.

I think the first one would be good. I'm not sure about the second case. But I'm not convinced the third case is desirable (It would mean that on not statically typed code calling a Callable with () is slower than with .call()).

It would inevitably be slower, there's not really any way around it. Regarding static typing, I don't want to introduce syntax that is only available with static typing, so either it works for everything or it doesn't work.

[Mickeon]

It's a shame there's so many intricacies to have this working, because it's a pretty simple and natural feature to have, on the surface.

[ryanabx]

It's a shame there's so many intricacies to have this working, because it's a pretty simple and natural feature to have, on the surface.

Yeah, it's a feature that typescript has, at the very least. I'm positive other languages have it as well, maybe python too. Those languages are structured differently than GDScript though 😕

[ryanabx]

I thought about how other languages handle functions being contained in variables, and I concluded that if we treated all functions like objects, similar to JavaScript, then we would consider class methods as properties of an instance of a class, not in a separate list of methods. Changing all the current places where methods and properties are separate would take a lot of work, though. Probably more work than it's worth. There's also ClassDB to consider, which treats methods differently than properties...

[theraot]

@ryanabx I can think of three ways to do it, none of which works for GDScript:

• Everything is a property, so all calls take the same pathway (like in JavaScript)
• Different syntax to access variables vs methods, so it is not ambiguous (like in PHP)
• Fully statically typed, so no runtime checks (like in C#)