Is there a proper way to connect a lambda to a signal?

Here's how it works:

• if a ambda does not use anything from the object, it will survive object deletion if a signal is connected to it.
• if it uses something from the object, it will be gone when object is deleted and signal will automatically be disconnected.

DaveTheCoder Are you sure? That sounds backwards.

Test it out.

Callable can be a method or a standalone function. If it's associated with an object, then it's considered a method. You can check if there is object association via Callable::get_object(). If a lambda is accessing any properties it will be magically treated as a method. Otherwise as a standalone function.

So if a connected lambda has an object association (is a method), the signal connection will be broken when the associated object is destroyed. If there is no object association then the labmda will live "forever".

jumpingmechanic It's not about "cleverness" of the system.

The system can only know about the function that is actually connected. If this function is a method associated with an object, then it can be disconnected in the case of that object's destruction. If you connect an object-less lambda (like in your example), then the connection is not associated with any objects. The fact that lambda's code is written in some class, doesn't make it associated with that object. (That's in fact the logical error in your reasoning). That lambda has no concept of self object and the object holds no reference to that lambda. From the object's point of view, the signal connection to that lambda is as if it was connected to some other object. So it's not that object's responsibility to disconnect the signal connected to the lambda.

Tldr, the "cleverness" you here expected from the system would actually make no sense and is not feasible.

jumpingmechanic The object association is stored with every Callable object. You can get it via Callable::get_object(). If you use the keyword self inside lambda body it will get associated with the object running the script (i.e. the object self refers to in that context). Otherwise it won't get associated with any object and get_object() will just return a reference to the Script object its code is written in.

So it doesn't matter what object(s) the lambda is referencing. What matters is the usage of self keyword.

var s = self
	
var a: Callable = func(): print(self)
var b: Callable = func(): print(Node.new())
var c: Callable = func(): print(s)
	
print(a.get_object())
print(b.get_object())
print(c.get_object())

jumpingmechanic Yes, because only those lambdas store the object reference, and the object keeps them in its internal list of incoming connections along with connections to its regular methods.

This can also be verified. The following will print only one of the lambdas as object's incoming connection:

ready.connect(func(): pass)
ready.connect(func(): self)
for c in get_incoming_connections():
	if c.signal == ready:
		print(c.callable)

So when the object is about to be deleted, it goes through the list of its incoming connections and disconnects the callables found in that list from their corresponding signals.

You can also verify this by looking at the Object class destructor in engine's source code. From Object::~Object() in object.cpp.

// Disconnect signals that connect to this object.
while (connections.size()) {
	Connection c = connections.front()->get();
	Object *obj = c.callable.get_object();
	bool disconnected = false;
	if (likely(obj)) {
		disconnected = c.signal.get_object()->_disconnect(c.signal.get_name(), c.callable, true);
	}
	if (unlikely(!disconnected)) {
		// If the disconnect has failed, abandon the connection to avoid getting trapped in an infinite loop here.
		connections.pop_front();
	}
}

Note that it calls Callable::get_object():