@Node macro

[samdeane]

I don't love the name or ergonomics of the @SceneTree macro.

The path: label for the argument is visual noise.

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.

This PR introduces a @Node macro. It uses the same macro implementation as @SceneTree, but tweaks the interface to be:

@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.

[migueldeicaza]

We should get it documented. I believe the docs might still point to the original version that might have used property wrappers and was very flaky. The one that came before SceneTree

[samdeane]

I've updated the docs and examples to use @Node instead of @SceneTree.

Also removed the references to the old BindNode.

Preview of the new docs included below:

[samdeane]

Is it worth deprecating or even removing BindNode?

[migueldeicaza]

I think we should deprecate BindNode, it relies on some runtime reflection, which turns out breaks on some platforms as the reflection produces different (and non-deterministic) output.

[migueldeicaza]

Just to confirm: old code using SceneTree will continue to work right?

(I do not use it myself, but I rather not break people's code).