GDScript: property setters do not work with curried lambda functions

[simast]

Godot version

v4.0.beta9.official [e780dc3]

System information

Windows 11

Issue description

As per the docs we can assign a function directly to a property setter:

var my_prop := 1.0:
	set = my_setter

Also the docs suggest that this can be used to "share the code across multiple properties". However this does not work with currying and lambda functions (see example in Steps to reproduce).

The reported error is:

Parse Error: Expected end of statement after property declaration, found "(" instead.

Steps to reproduce

Example code with the issue:

var prop: float:
	set = set_float_prop(&"prop")


func set_float_prop(param: StringName):
	return func (value: float):
		self[param] = value

Minimal reproduction project

N/A

[KoBeWi]

share the code across multiple properties

This just means that you can assign the same function to multiple properties (although not sure how does that work).

Looks like setter expects a method identifier, not a true callable. Which means you can't use Callable(...) either.

[dalexeev]

Also the docs suggest that this can be used to "share the code across multiple properties".

The sentence in the docs is a bit confusing. At the moment, you can share the same setter/getter between multiple properties, but have no way of distinguishing which property it's being called on. See:

• Automate or reduce the boilerplate when forwarding script properties in GDScript godot-proposals#6750
• Allowed setters and getters to take additional arguments (superseded by #78991) #76665

As for argument binding, this is difficult to implement, see godotengine/godot-proposals#6750 (comment):

Binding arbitrary arguments sounds useful, but it's probably complex to implement. Functions are not Callables, they just create Callables at runtime when referenced. So to properly call the setter/getter with binds those would need to be stored in the script and passed as arguments at runtime. If you want non-constant values it becomes more difficult because it would need to store expressions to be executed when calling. I don't think this is worth the hassle.

I suggest closing the issue, as this is not a bug, but an intentional limitation for performance reasons. There are already several proposals related to the problem.