Add C# signal automatic disconnection info

[31]

After #8812, I looked a bit further at this Delegate.Target quirk that I remember noticing a while ago but hadn't looked into. This is just based on experimentation rather than tracking it down in Godot/.NET source, so I'm not 100% sure my reasoning is correct.

I don't know if all this specific stuff is already tracked by godotengine/godot#70414 / godotengine/godot#73730, or if there's more to pull out into a separate functional issue. This has been at the back of my mind for a while since it comes up in the C# Discord chat fairly often, so I figured now that I've looked into it a bit more, I'd just write it as a doc either way. 😅

[paulloz]

This seems fine to me. The ordering within the page is just a bit odd now:

• Signals as C# events
• Disconnecting automatically when the receiver is freed
• Custom signals as C# events
• Signal emission
• Bound values
• Signal creation at runtime
• Using Connect and Disconnect

Maybe the new section should instead be moved at the very end, or before the last one?

[31]

Good point, I didn't really consider the order all that carefully. Adding it at the bottom makes sense to me.

That makes me think about how I expect people to actually get here... I think calling it out in the summary with the type of exception someone is probably seeing if they've hit this quirk is a good way to go.

Pushed the changes.

[raulsntos]

All of this has made me realize how complicated C# signals are at the moment. I feel like users shouldn't need to know all this just to use signals in C#, but since that's the current state of things it's better to document it than to leave users confused.

[31]

Yeah, initially I thought using .Connect was solving everything and the situation was ok, but this is quite unfortunate.

If we end up stuck here, I think it might be simpler if the docs included manual disconnection everywhere for C#, and this page mentioned that automatic disconnection happens in a few specific cases. That's a pretty big change though, and if godotengine/godot#73730 ends up making things simpler (or ends up with us manually tying references to our delegates to the lifetime of a Godot object, or... something), not sure it's worth too much churn simplifying where we're at now.

[raulsntos]

This looks good to me as it is now. We can update the docs again when/if godotengine/godot#73730 gets merged, which is not guaranteed to make it in 4.3.

[mhilbrunner]

Thank you!