-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
bevy_reflect: Add ReflectClone type data
#18211
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
base: main
Are you sure you want to change the base?
Conversation
|
Note that with #18307 this will probably need to be rebased since it will cause a lot of errors where |
|
Cutting from the milestone, but please feel free to explain why this is vital / part of a larger whole. |
That's no problem! The main reasons we want this in general are:
That last one is probably the more useful, but I guess I forgot to include it in the description haha. |
|
Okay that makes sense to me :) We'll get this in eventually, but not critical to block on. |
2 similar comments
|
Okay that makes sense to me :) We'll get this in eventually, but not critical to block on. |
|
Okay that makes sense to me :) We'll get this in eventually, but not critical to block on. |
Objective
This PR is a partial followup to #13432, but is not based on that branch as it also works as a completely standalone change.
The goal of this PR is to add reflection type data for the
Clonetrait.For #13432, this is desired because it addresses inconsistencies mentioned in this comment (which are further addressed in #13723). Namely, we should try to reduce the split between special trait type data registration and regular trait type data registration.
Apart from that PR, this PR should allow users to create concrete clones within reflection much easier.
For reference, here are some ways cloning is typically handled:
Those solutions are also not ideal since some types do extra things when cloned (e.g. increasing a ref-count). It would be better if we could call that
Cloneimpl directly via reflection.Solution
This PR simply introduces a
ReflectClonetype data struct that can be registered like any other type data (assuming the type implementsClone).This simplifies our above approach:
Note that with #13432 this is even simpler, but this provides a solid alternative if needing to use type data (or if wanting to specially handle types that implement
Clone).Testing
You can test locally by running:
Showcase
Reflected types that implement
Clonecan now register theReflectClonetype data, allowing for reflected values to be directly cloned.