Revisiting nil
semantics in Variant
and TypedArray
#576
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following changes, all of them are related to
nil
-correctness.Variant
withgtype == .nil
should never surface in the user API. It will be always represented as Swiftnil
ofVariant?
. This allows direct integration of Swift nullability checks into Variant processing. We shouldn't have places where we haveVariant?.some
withGodot
nil
inside. This is accompanied with a lot of small code changes everywhere in the code to support this logic.Variant
will now beVariant?
.ObjectCollection
: TypedArray of objects can now work withnils
(just like it does in GDScript).Nil
builtin class is omitted from translation.Arguments
to streamline gracious failing when Godot calls are done into@Callable
or@Exported
. It shouldn't crash the game/editor anymore and print errors instead.MacroCallable
andMacroExported
for newer infrastructure and gracious failing if Godot calls into Swift-exported code with wrong arguments instead of crashing.