Release 0.60.1

Swift bindings for Godot 0.60.1 release

We did a big jump from version 0.50 to 0.60 as this contains a large set of improvements to the binding thanks to Elijah Semyonov. Unless otherwise noted, the contributions were done by Elijah.

This is a large set of improvements that vastly improve the performance, reliability, usability and correctness of SwiftGodot andwe have tested this on a very large SwiftGodot app (Xogot). There are some changes required to your code, but the changes required are
simple, and detailed below.

Perhaps the biggest surprise is that the new TypedArray needs the T to be optional whenever you are dealing with a Godot Object, so you can now have things like: TypedArray<Int> and TypedArray<Node?> as well as the signal connection operations no longer returning an Object token that you pass to disconnect, but instead a Callable token that you must pass to disconnect.

Changes

Callable and Signals

• @Export-able Swift closures properties proxied via Callable
• Make Callable constructor taking an arbitrary Swift closure, where arguments and return types are bridgeable Gogot types. No manual working with Arguments anymore! :)
• Godot -> Swift calls are now heap-allocation free. We no longer need heap-allocated Variants neither for argument extraction, nor returned value. FastVariant is nice!
• Refine SignalWithArguments make it a struct. Make it reference wrapped object weakly (not preventing Swift from destroying it). That prevents signals from retaining the target object, which could lead to unexpected memory leaks. This behavior aligns with Godot Signal.
• Deprecate SignalWithArguments.emitted, it's unsafe and will leak coroutine state referenced by continuation and captured context if it's never fired.
• @callable macro now supports an autoSnakeCase parameter if you want to have this applied directly to your function to surface in a Godot-friendly way.

Collection Changes

• Rename GArray to VariantArray. Leave deprecated typealias.
• Introduces TypedArray uniting functionality of ObjectCollection and VariantCollection. It's almost fully source compatible but will require inserting some ? in existing code, but Swift didn't allow to avoid it. ObjectCollection and VariantCollection are deprecated type aliases to TypedArray. Migrating requires changing occurrences of ObjectCollection<Type> to TypedArray<Type?>
• Introduce GodotBuiltinConvertible, a happy sibling of VariantConvertible that can proxy user type via specific Godot builtin instead of general purpose Variant.
• Remove all special treatments of Swift.Array. It's simply conforming to GodotBuiltinConvertible if its elements are valid TypedArray elements ( builtin types, or Optional Object-derived types).
• Change semantics of VariantArray to TypedArray conversion slightly. Now it follows the Godot rules: if conversion fails, it returns an empty (but typed!) array.
• Constrain registration API to Object.Type instead of Wrapped.Type. It allows us to store Object-inherited classes metatypes of both framework types and user types for future improvements.
• Godot proc addresses static storage is moved to a separate case-less enum for each builtin type. It is called GodotInterfaceFor{TypeName}. This is also a groundwork for per-class procs caches that should be manually flushed in projects like Xogot. Later this enum with static storage (or computed properties in case of Xogot) can be converted into a struct with instance properties stored into a global variables like var giNode: GodotInterfaceForNode!, similar to how general GodotInterface is stored in var gi: GodotInterface!.
• Rename Dictionary to VariantDictionary. Leave deprecated typealias.
• Implement TypedDictionary which behaves similar to TypedArray and facades Godot typed dictionary.
• Make Swift.Dictionary a bridgeable type via GodotBuiltinConvertible.
• Make Godot class builtins Hashable if they have hash() function.

Strings

• String marshaling directly to and from FastVariant and Variant avoid allocation of GString class instance
• Introduce FastStringName, a special kind of StringName that allows wrapping StaticString (Swift string with static storage), which allows avoiding allocations when StringName is constructed from non-interpolated String literal.
• Use FastStringName in generated code during proc address retrieval.
• Throw diagnostics error for an attempt to macro static members (was never supported).

Core - Variants

Internally, the VariantStorable and VariantRepresentable were replaced with the new VariantConvertible and a family of operations that simplified plenty of the operations on variants, removed boilerplate and ad-hoc hacks in various places.

This allowed the various macros in the SwiftGodot family to rely on the compiler and its type inference system to do the heavy-lifting when exposing types rather than rely on processing the syntax and attempting to cover various type scenarios.

This means that we now have a more reliable, more Swift-y way of working and will reduce surprised in the future for corner cases, as it is now the compiler doing the work, not relying on the macro to perform good guesses (Elijah)

• All macro logic related to @Export, @Callable and @Godot relies on static dispatch into correctly selected overloaded functions for inferring PropInfo. That effectively removes a need for our handicapped attempt of type analysis based on SwiftSyntax.

• .enum hints are filled automatically for @Export when eligible.

• No explicit type information is needed for Node, @Export-ed properties anymore.

• All places that need to distinguish nullability of marshalled types now do it according to Godot rules. Builtin types are never
  null. Objects subclasses and Variant are nullable and can be
  constrained to non-nullable on Swift side.

• Code-generated SignalWithArguments now properly infers nullability
  according to these rules.

• Names of arguments of @Callable are now correctly processed if they use MemberTypeSyntax (aka qualified names).

• VariantStorable and VariantRepresentable are removed. Source-compatibility still stays, if they were not used directly.

• Nice APIs to tackle Variant conversions. variant.to(Int.self), 50.toVariant(), Variant("Hello"), String(variant), everything is possible, except Object(variant) that won't crash runtime anymore, it simply doesn't exist.

• Introduce lightweight FastVariant that doesn't require a heap allocation.

• Integrate FastVariant for extraction specific types from Arguments. No heap allocations for each extracted argument, FastVariant temporarily borrows VariantContent provided by Godot to extract types we are interested in.

• Make a lot of Variant APIs @inlinable so that compilation of user projects can optimise access to those APIs.

• All VariantConvertible types are compatible with macros. They will surface as Variant in Godot.

Interoperability

• The @godot Macro generates fully qualified typenames to avoid clash with user
  typenames.

Initialization

• #initSwiftExtension macro will topologically sort the classes to register and deregister them in the right order. This is especially important for proper functioning of EntryPointGeneratorPlugin, which emits meta type elements in the order of files and syntax traversal.

Internals

• Cleaned up macro library. Dead code for type analysis was removed. SwiftSyntax queries specific to Godot were moved to corresponding *Syntax extensions. Now code is much easier to follow. A little brother of Generator.Printer was brought to macro library to avoid indentation mess during code generation.
• Macro-generated code is completely detached from ClassInfo. It's a prerequisite for a future improvement, where registration and reregistration happens proactively during extension initialisation. classInitializer will be replaced with a static var classDescriptor allowing topological sorting and and other lazy inference where information about all generated classes is available.

4.4 Support

• This bring support for the 4.4 API update (Gabor Koncz, Miguel de Icaza)

• Godot 4.4 Typed Dictionaries are now supported (Elijah)

Note

Release 0.60 was tagged, but there were a handful of small issues that prevented from this being a glorious release, so we added a couple of fixes.