-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
[Merged by Bors] - bevy_reflect: Fix apply
method for Option<T>
#5780
Conversation
I just added a test which subsequently alerted me of another bug which has been fixed as well. |
}) | ||
.clone_value() | ||
.take::<T>() | ||
.unwrap_or_else(|value| { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable for the current impl. Stuff like this makes me want to revisit mixing "dynamic type" reflection and "actual type" reflection. But thats a conversation for another day :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like a good time to revisit bevyengine/rfcs#56 😉
bors r+ |
# Objective #5658 made it so that `FromReflect` was used as the bound for `T` in `Option<T>`. However, it did not use this change effectively for the implementation of `Reflect::apply` (it was still using `take`, which would fail for Dynamic types). Additionally, the changes were not consistent with other methods within the file, such as the ones for `Vec<T>` and `HashMap<K, V>`. ## Solution Update `Option<T>` to fallback on `FromReflect` if `take` fails, instead of wholly relying on one or the other. I also chose to update the error messages, as they weren't all too descriptive before. --- ## Changelog - Use `FromReflect::from_reflect` as a fallback in the `Reflect::apply` implementation for `Option<T>`
Pull request successfully merged into main. Build succeeded: |
apply
method for Option<T>
apply
method for Option<T>
# Objective bevyengine#5658 made it so that `FromReflect` was used as the bound for `T` in `Option<T>`. However, it did not use this change effectively for the implementation of `Reflect::apply` (it was still using `take`, which would fail for Dynamic types). Additionally, the changes were not consistent with other methods within the file, such as the ones for `Vec<T>` and `HashMap<K, V>`. ## Solution Update `Option<T>` to fallback on `FromReflect` if `take` fails, instead of wholly relying on one or the other. I also chose to update the error messages, as they weren't all too descriptive before. --- ## Changelog - Use `FromReflect::from_reflect` as a fallback in the `Reflect::apply` implementation for `Option<T>`
# Objective bevyengine#5658 made it so that `FromReflect` was used as the bound for `T` in `Option<T>`. However, it did not use this change effectively for the implementation of `Reflect::apply` (it was still using `take`, which would fail for Dynamic types). Additionally, the changes were not consistent with other methods within the file, such as the ones for `Vec<T>` and `HashMap<K, V>`. ## Solution Update `Option<T>` to fallback on `FromReflect` if `take` fails, instead of wholly relying on one or the other. I also chose to update the error messages, as they weren't all too descriptive before. --- ## Changelog - Use `FromReflect::from_reflect` as a fallback in the `Reflect::apply` implementation for `Option<T>`
# Objective bevyengine#5658 made it so that `FromReflect` was used as the bound for `T` in `Option<T>`. However, it did not use this change effectively for the implementation of `Reflect::apply` (it was still using `take`, which would fail for Dynamic types). Additionally, the changes were not consistent with other methods within the file, such as the ones for `Vec<T>` and `HashMap<K, V>`. ## Solution Update `Option<T>` to fallback on `FromReflect` if `take` fails, instead of wholly relying on one or the other. I also chose to update the error messages, as they weren't all too descriptive before. --- ## Changelog - Use `FromReflect::from_reflect` as a fallback in the `Reflect::apply` implementation for `Option<T>`
Objective
#5658 made it so that
FromReflect
was used as the bound forT
inOption<T>
. However, it did not use this change effectively for the implementation ofReflect::apply
(it was still usingtake
, which would fail for Dynamic types).Additionally, the changes were not consistent with other methods within the file, such as the ones for
Vec<T>
andHashMap<K, V>
.Solution
Update
Option<T>
to fallback onFromReflect
iftake
fails, instead of wholly relying on one or the other.I also chose to update the error messages, as they weren't all too descriptive before.
Changelog
FromReflect::from_reflect
as a fallback in theReflect::apply
implementation forOption<T>