Skip to content

Support disconnection for type-safe signals #1113

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ColinWttt opened this issue Mar 31, 2025 · 2 comments
Open

Support disconnection for type-safe signals #1113

ColinWttt opened this issue Mar 31, 2025 · 2 comments
Labels
c: core Core components feature Adds functionality to the library
Milestone

Comments

@ColinWttt
Copy link
Contributor

Related to #1000

self.signals().my_signal().disconnect(...);
// may be?
self.signals().my_signal().disconnect_all()
@Yarwin Yarwin added feature Adds functionality to the library c: core Core components labels Mar 31, 2025
@Bromeon Bromeon added this to the 0.3.x milestone Mar 31, 2025
@Bromeon
Copy link
Member

Bromeon commented Mar 31, 2025

Lower priority, since this can (likely) be added in a backwards-compatible way and thus shouldn't block 0.3.0 release.

Disconnecting by passing in the same function again is unreliable, especially for closures and other ad-hoc FnMut objects. Ideally we could go for such an API:

let handle = self.signals().my_signal().connect(...);

handle.disconnect();

But since we still have to rely on underlying Signal::disconnect(Callable) or Object::disconnect(StringName, Callable) APIs, we have to see whether that's feasible -- maybe by crafting a custom Callable that has the same hash as the original one and compares equal.

If this doesn't work out, users would need to pass in a custom ID (maybe through connect_builder()).

@Bromeon
Copy link
Member

Bromeon commented May 4, 2025

Maybe related, we should check what to do with connected signals once their object dies (e.g. through queue_free).
At the moment, connected signals panic with:

{Class}::bind_mut: access to instance with ID {id} after it has been freed

Maybe auto-disconnect is an option in cases where the object is known to godot-rust (passed in as connect_self/connect_other argument)? Or a detection + more precise warning + advice to disconnect signals on death?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: core Core components feature Adds functionality to the library
Projects
None yet
Development

No branches or pull requests

3 participants