Mix-ins, manually registered #[methods] blocks applicable to multiple types

[chitoyuu]

It has been a long-standing limitation that only one #[methods] blocks can be exposed for any given type. There are many reasons why it's desirable to remove this limitation:

• Generally, Rust puts no restriction on the number of impl blocks a type might have. It's natural to want to use multiple impl blocks for code organization.
• It's nice to be able use traits to group common functionality together, so a consistent GDScript interface can be enforced by the compiler.
• Traits can also potentially be used to simplify the process of correctly overriding an engine virtual method (e.g. _ready). Some interesting experiments are being done in the GDExtension bindings, centered on a curated set of methods.

In light of #983, there's also a new important use for the ability: to declare multiple impl blocks with different bounds, which is critical for the usefulness of generic types.

Design

The public interface would be fairly simple, and compatible with the existing API:

#[derive(Clone, NativeClass)]
#[register_with(register_mixins)]
struct Foo;

#[methods(as = "InherentMixin")]
impl Foo {
    #[method]
    fn foo() {}
}

#[methods(as = "TraitMixin")]
impl<C> MyDeepCloneTrait for C
where
    C: NativeClass + Clone,
{
    #[method]
    fn duplicate(&self) -> Instance<C> {
        Instance::emplace(self.clone()).into_shared()
    }
}

fn register_mixins(builder: &ClassBuilder<Foo>) {
    builder.mixin::<InherentMixin>();
    builder.mixin::<TraitMixin>();
}

Here, the presence of the #[methods(as)] argument tells the macro to generate a mixin type called MyMixin, instead of an ordinary NativeClassMethods implementation. A mixin type is an opaque type with no public interface, that serves as a handle to pass into ClassBuilder::mixin, which will then perform registration.

It's important that a type is generated instead of a plain register function here: the latter does not have a nameable type. While it doesn't make a lot difference for simple use cases with manual registration, they can be useful for type-based shenanigans in the future, should we find ourselves having to expand the internal interface beyond just a single function.

Internally, #[methods] (without the as argument) could be refactored to generate an unnameable mixin that is immediately wrapped into a NativeClassMethods. This behavior can be removed in a future breaking version where we introduce automatic registration for inherent impls (on supported platforms, see #350), and remove the NativeClassMethods trait completely.

[Bromeon]

Nice to have a type name as a differentiator!

Question for my understanding:

#[methods(as = "TraitMixin")]
impl<C> MyDeepCloneTrait for C
where
    C: NativeClass + Clone,
{
    #[method]
    fn duplicate(&self) -> Instance<C> {
        Instance::emplace(self.clone()).into_shared()
    }
}

This would still need an explicit monomorphization as in #983, in order to expose duplicate to GDScript, correct? I assume the handle TraitMixin itself is not generic?

[chitoyuu]

This would still need an explicit monomorphization as in #983, in order to expose duplicate to GDScript, correct? I assume the handle TraitMixin itself is not generic?

Yes. The TraitMixin itself is not generic, but will have a generic impl on it, so it can be registered to different types. For manual registration the impl will be monomorphized in builder.mixin::<TraitMixin>(), as shown later in the example.

I'm not very optimistic about automatic registration of generic impls like this in the near future. For one thing, it will likely require specialization in some form, which isn't coming to stable any time soon. Even with that cleared, there would still be the problem of somehow coercing Rust into monomorphizing NxM combinations, where both sets N and M are only known at runtime, as is the case with inventory.

[chitoyuu]

I'm starting to think that perhaps this should just be rolled out together with #350, so we don't have to write all the diagnostic code and UI tests just to do it all over again. It would be a lot better if the code was aware of platform availability of auto registration right from the start.

#350 has to be a non-breaking change anyway (due to WASM), so that yak might as well get shaved right now.