New memory management system

A new document MemoryManagement.md document the new system, but for existing users of SwiftGodot, there are a number of important considerations:

• As we have explored in the past, SwiftGodot objects that point to Godot objects could be destroyed by Godot behind our back. For example, if you create a Node, give it to Godot, and Godot destroys it, but you still had a pointer left to it.

There was no way of determining that this had happened, so you could get a crash. Now, when this scenario ocurs, we clear the handle in the Godot object, which will do two things: you can now call isValid on these objects to determine if the object is still valid, and if you forget, a new exception will be raised for you to be able to pinpoint those cases.

• In the past, it was possible for tthe same Godot object would be surfaced to Swift with different wrapper objects. This worked fine because we kept no state on them.

• In the past, SwiftGodot released all objects when they went out of scope, following the idiom of Swift and automatic reference counting.

This was not quite correct. With this release, only RefCounted objects (Resources-subclasses are one of the main users) get the automatic reference counting behavior. Subclasses of Node need to be manually released with Node.queueFree, and other non-Node, non-RefCounted objects must be manually released with Object.free.

The above was implemented by Gabor Koncz, Miguel de Icaza.

New Variant Binding

In the past, our Variant type would contain the special .nil type, so when you got a Variant, to test for this, you would need to check this value. In some APIs that meant first checking Variant was non-nil, then checking for the .nil state in the Variant. It felt bad.

This new version of the binding maps a Godot .nil value in a Variant to Swift's nil, ensuring that if you ever have a Variant, it will never contain the nil value. This does impact many existing signatures that took Variant or [Variant], as they become Variant? and [Variant?].

I have deployed this on a large app, and the results are very pleasant.

This was a contribution that was carefully developed over many weeks by Elijah Semyonov. Thank you Elijah!

Signals

New @Node Macro

Sam Deane contributed a new @Node macro that replaces the old @SceneTree macro and should be used instead of the flaky BindNode property wrapper.

Requiring the variable type to be optional or implicitly unwrapped also doesn't quite make sense - we may as well support it being non-optional. For non optional variables we'll get a runtime error if the node is missing, which is also true for implicitly unwrapped vars.

It works like this:

@Node("nodePath") var myRequiredNode: SomeNodeType
@Node("nodePath") var myOptionalNode: SomeNodeType?

The scene tree macro implementation has been tweaked to support non-optional type definitions, rather than complaining about them. It does still support implicitly unwrapped types, for backwards compatibility with @SceneTree, which remains unchanged.

Generic Signal

A new approach to signals that unifies the signals generated by SwiftGodot. Fixes a long-standing bug [#587], and long-standing [#42]. Lovely contribution by Sam Deane.

New @Signal Macro

Adds a new @Signal macro, giving a cleaner and more consistent way to add user-defined signals from Swift.

@Godot
class MyNode: Node {
  @Signal var mySignal: SimpleSignal
  @Signal var signalWithArgs: SignalWithArguments<Int, String>
}

These signals can be used in the same way as built-in signals:

node.mySignal.connect { /* do something */ }

node.signalWithArgs.connect { intArg, stringArg in
  // do something
}

node.mySignal.emit()
node.signalWithArgs.emit(1, "foo")

The existing #signal macro defines the signal as a static property on the class that contains it.

This is different from the generated implementation of built-in signals, and means that we have to use a different syntax to work with them -- which was non-optimal.

Changes

• Now requires Swift 6.0 (Sam Deane)

• Windows build improvements by Sam Deane

• Surfaced support for editorAddPlugin and editorRemovePlugin to allow developers to create Godot editor plugins.

• Introduces a new EntryPointGenerator plugin for all @Godot classes in the project (Elijah)

• Various documentation, test suite improvements, warning fixes and generator, refactoring changes and internal maintenance and quality of life improvements (Chris Backas, Sam Deane, Elijah Semyonov, Rob Mayoff, Gabor Koncz, Gianluc Lui, Miguel de Icaza).

• Plenty of new convenience initializers for the Packed*Array types by Gianluc Lui.

• New Variant.getNamed(key:) API

• Small cleanups to our sample code (Sam Deane)

• Enumerations no longer generate debugDescription as it was not necessary - reducing the API surface (Sam Deane)

• Android support by Marc Prud'hommeaux. Nice tutorial on how to use SwiftGodot on the Meta Quest by Tomasz Wyrowiński is here: https://github.com/tomwyr/godot-swift-meta-quest-minimal/

• @Callable methods now can take optional values #669

• The @Export attribute can now specify PropertyUsage flags, if none is provided, it will continue to default to .default.

• New support for overwriting the Godot _validate_property method, in SwiftGodot, the method to overwrite is _validateProperty and it can be used to change the property usage flags of a dynamic property.

Fixes

• #581
• #579
• #613
• #624