New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Derive NativeClass for known monomorphizations of generic types #601
Comments
This would likely require some reworking of the |
This would be a useful feature indeed. May I ask how this affects existing code (since it's marked as a breaking change)? It technically splits From #842 (comment):
Regarding class name, we might also want to consider #603. I think it would be nice, if for non-monomorphized types, the following would be possible:
I have no problem with using |
Exactly what you said. It affects manual
We can support that by using the new trait as a generic bound of impl InitHandle {
pub fn add_class<C: NativeClass + StaticallyNamed>(self) {
self.add_class_with_name(C::class_name()) // now a member of StaticallyNamed
}
pub fn add_class_with_name<C: NativeClass>(self, name: &str) {
// -- original impl of add_class --
}
} |
And So the derive-macro would detect whether it's applied to a generic class (-> no name) or not (-> name)? Sorry for the many questions, maybe it's best if I just look at your implementation 🙂 |
Having I'll try to make a PR this weekend. |
No, I think having less work left to the user (i.e. implicit) for non-generic types is better. Thanks a lot, and no rush! 🙂 |
This allows NativeScript types to be registered under names only determined at run time, enabling better ergonomics for libraries. Ref godot-rust#601, godot-rust#603
This allows NativeScript types to be registered under names only determined at run time, enabling better ergonomics for libraries. Ref godot-rust#601, godot-rust#603
847: Separate static name from `NativeClass` into new trait r=Bromeon a=chitoyuu This allows NativeScript types to be registered under names only determined at run time, enabling better ergonomics for libraries. Ref #601, #603 ## Unresolved questions This does not implement the `#[name = "MyCustomName"]` static renaming syntax as suggested in #601 (comment), because it's very uncommon (if at all possible) for a key-value pair to be the top-level meta in an attribute. It should also be noted that at this moment, the `NativeClass` macro already utilizes a large number of type-level attributes: - `inherit` - `user_data` - `register_with` - `no_constructor` ...so it might not be wise to add another into the mix, especially under such a non-specific identifier as `name`. We might want to consider bundling (some of) these into a single top-level attribute (like `variant` for the `From`/`ToVariant` macros) instead. See #848. Co-authored-by: Chitose Yuuzaki <chitoyuu@potatoes.gay>
847: Separate static name from `NativeClass` into new trait r=Bromeon a=chitoyuu This allows NativeScript types to be registered under names only determined at run time, enabling better ergonomics for libraries. Ref #601, #603 ## Unresolved questions This does not implement the `#[name = "MyCustomName"]` static renaming syntax as suggested in godot-rust/gdnative#601 (comment), because it's very uncommon (if at all possible) for a key-value pair to be the top-level meta in an attribute. It should also be noted that at this moment, the `NativeClass` macro already utilizes a large number of type-level attributes: - `inherit` - `user_data` - `register_with` - `no_constructor` ...so it might not be wise to add another into the mix, especially under such a non-specific identifier as `name`. We might want to consider bundling (some of) these into a single top-level attribute (like `variant` for the `From`/`ToVariant` macros) instead. See #848. Co-authored-by: Chitose Yuuzaki <chitoyuu@potatoes.gay>
847: Separate static name from `NativeClass` into new trait r=Bromeon a=chitoyuu This allows NativeScript types to be registered under names only determined at run time, enabling better ergonomics for libraries. Ref #601, #603 ## Unresolved questions This does not implement the `#[name = "MyCustomName"]` static renaming syntax as suggested in godot-rust/gdnative#601 (comment), because it's very uncommon (if at all possible) for a key-value pair to be the top-level meta in an attribute. It should also be noted that at this moment, the `NativeClass` macro already utilizes a large number of type-level attributes: - `inherit` - `user_data` - `register_with` - `no_constructor` ...so it might not be wise to add another into the mix, especially under such a non-specific identifier as `name`. We might want to consider bundling (some of) these into a single top-level attribute (like `variant` for the `From`/`ToVariant` macros) instead. See #848. Co-authored-by: Chitose Yuuzaki <chitoyuu@potatoes.gay>
847: Separate static name from `NativeClass` into new trait r=Bromeon a=chitoyuu This allows NativeScript types to be registered under names only determined at run time, enabling better ergonomics for libraries. Ref #601, #603 ## Unresolved questions This does not implement the `#[name = "MyCustomName"]` static renaming syntax as suggested in godot-rust/gdnative#601 (comment), because it's very uncommon (if at all possible) for a key-value pair to be the top-level meta in an attribute. It should also be noted that at this moment, the `NativeClass` macro already utilizes a large number of type-level attributes: - `inherit` - `user_data` - `register_with` - `no_constructor` ...so it might not be wise to add another into the mix, especially under such a non-specific identifier as `name`. We might want to consider bundling (some of) these into a single top-level attribute (like `variant` for the `From`/`ToVariant` macros) instead. See #848. Co-authored-by: Chitose Yuuzaki <chitoyuu@potatoes.gay>
847: Separate static name from `NativeClass` into new trait r=Bromeon a=chitoyuu This allows NativeScript types to be registered under names only determined at run time, enabling better ergonomics for libraries. Ref #601, #603 ## Unresolved questions This does not implement the `#[name = "MyCustomName"]` static renaming syntax as suggested in godot-rust/gdnative#601 (comment), because it's very uncommon (if at all possible) for a key-value pair to be the top-level meta in an attribute. It should also be noted that at this moment, the `NativeClass` macro already utilizes a large number of type-level attributes: - `inherit` - `user_data` - `register_with` - `no_constructor` ...so it might not be wise to add another into the mix, especially under such a non-specific identifier as `name`. We might want to consider bundling (some of) these into a single top-level attribute (like `variant` for the `From`/`ToVariant` macros) instead. See #848. Co-authored-by: Chitose Yuuzaki <chitoyuu@potatoes.gay>
While it's impossible to derive
NativeClass
in the general case due to monomorphization, it should be possible to export a list of monomorphizations specified by the user. This is most useful when a user needs to wrap a Rust data structure in a NativeScript, and know the list of types necessary.Suppose that we have a
GridMap
type that efficiently stores a value for each tile in a 3D space, for example. Currently, we can wrap it in aNativeClass
like this:We can, then, create and use
GridMap
s containingi32
s in GDScript. However, suppose that we now also want to be able to createGridMap
s that contain strings instead. BecauseNativeClass
andmethods
don't support generics yet, we have no option but to copy and pasteGridMapInt
, along with its 100 extra wrapper methods, which is obviously terrible, or use code generation, which is rather inconvenient. Both options will also limit how one can interact with those wrapper types from Rust, since they are not generic.Instead, with a syntax for explicitly exporting certain monomorphizations, we would be able to write something like:
...which could expand to:
Alternatives
Attributes on the original type instead of type aliases
Instead, we could also put the list of generic arguments above the type for which
NativeScript
is derived:There shouldn't be any implication on implementation difficulty or auto-registration, but I find this syntax much less convenient compared to the one with type aliases, due to how attribute syntax works. It also won't work as well with macros:
Opinions are welcome!
The text was updated successfully, but these errors were encountered: