GenericSignal helper class

[samdeane]

See also #42

Instead of generating a helper class for each signal property, we use a single GenericSignal which can be specialised with the list of argument types that the signal contains.

[samdeane]

Not sure the best way to comprehensively test this.

I think the one thing that might fail at runtime is the code that is unpacking the arguments to pass to the connect closure.

It is assuming that they can be constructed from a Variant. This should be true, but it's not the same code as was in the old generated helpers.

I've tested a bit with my own Godot project, but it would be good to try some others that make use of Godot-defined signals with parameters, and check that they work.

[samdeane]

I've cleaned up the formatting - the PR should now just contain the actual changes I've made.

[samdeane]

@migueldeicaza I thought I'd try bumping the version right up to 6.0.2 here to see if the Windows compiler's argument pack support was fleshed out, as I remember you speculating that it might not be fully functional in 5.10 on Windows.

The tests pass so I guess that it is.

I guess it might be worth setting the swift-tools-version to 6.0 if we truly do need Swift 6 on Windows - but then we'd have to add an explicit opt-out of the Swift 6 language model for now, to avoid having to deal with that whole can of worms...

[samdeane]

Note that with @elijah-semyonov's variant changes, I think the generic class has to deal with the possibility of one of the arguments passed to a signal-with-arguments could be nil.

I'm not sure if that's actually possible in reality? Since this code was written before that change was merged, for now I've just taken the simplest route and I throw an error for a nil argument, just like I would for one of the wrong type. I can probably eventually get nil arguments to work fine if they are needed, but I wanted to minimise the changes after rebasing, so it might be simpler to tackle it in a follow-up PR later.

[migueldeicaza]

The lack of support for nil is troubling, because there is a world where we would need to pass a nil that is being surfaced by Godot to our code.

One solution might be to bring back a Variant.Nil that conforms to VariantStorable so we can satisfy this signature:

    public func connect(flags: Object.ConnectFlags = [], _ callback: @escaping (_ t: repeat each T) -> Void) -> Object {

Or perhaps the only scenario we care about is passing an object that might be nil.

I think that we might be able to get away with creating such an object, and manually set the handle to nil, and users of that code would need to test for 'object.isValid'.

[migueldeicaza]

I am not a fan of 'object.isValid' approach, so perhaps we do need to introduce a Nil type, perhaps we can call it 'CallbackNil' to make it clear that it is to be generally shunned.

[samdeane]

The lack of support for nil is troubling

I've revised this so that nil arguments should be passed through to the callback properly.

[samdeane]

After further discussion with @elijah-semyonov I've changed the generator as he suggested, so that primitive signal arguments are non-optional, but object ones are optional, in the actual signature of the GenericSignal.

[migueldeicaza]

Thank you for nurturing this change.

Cheers!