Closed chitoyuu closed 1 year ago
bors try
This PR would allow users to use the Instance
and TInstance
types as receivers for their exported methods. Additionally, Arc<Self>
can also be used for types using the ArcData
wrapper, since it's already exposed via ArcData::into_inner
. All of the following declarations are now valid:
#[methods]
impl Foo {
#[method]
fn none() {}
#[method]
fn arc(self: Arc<Self>) {}
#[method]
fn instance(#[self] this: Instance<Self>) {}
#[method]
fn t_instance(#[self] this: TInstance<Self>) {}
}
@B-head Please see if this satisfies your main needs as mentioned here: https://github.com/godot-rust/gdnative/pull/1033#issuecomment-1430654640
CI failed because GATs were stablized in Rust 1.65, while our current MSRV is 1.63. We can probably bump it directly to the latest 1.67 unless there's a significant reason not to.
About 80% looks good. (My code uses Rc<T>
, so I have not tested it yat)
Can you support the emplace construct feature? It is useful to remove Option<T>
in the structure.
Can you support the emplace construct feature? It is useful to remove
Option<T>
in the structure.
This works with the existing system. Everything that works still do.
You can also still use Rc<T>
in your types. There's nothing restricting that.
bors try
Since we have bumped the MSRV and there's a general tendency for nightly clippy lints to be left unfixed until they become breaking, I've taken the liberty to change the Default
impl to a derived one for a type in gdnative-derive
.
Merging since this appears to solve the the original requirements that motivated the other PR.
bors r+
Instance
andTInstance
can now be used as self types where applicable. Additionally,Arc
is supported whenArcData
is used as the user-data wrapper.The
self
type can be provided through the standardarbitrary_self_types
syntax, or a#[self]
attribute on the argument when unavailable.This is technically a breaking change because all
UserData
errors are now required to implementstd::error::Error
, although the possibility of actual breakage should be pretty low -- the wrapper types we ship should be powerful enough to cover most if not all valid use cases.Close #974