Repository navigation
[Merged by Bors] - Support tuple structs with #[derive(SystemParam)] - #6957
joseph-gio wants to merge 1 commit into
Conversation
|
Note that this does not conflict with #6919. |
alice-i-cecile
left a comment
There was a problem hiding this comment.
This is correct and a natural extension. I don't think I'd ever use it myself though, and I'd complain against it being used in any project I was doing code review for.
Tuple structs are just generally kind of a mess to work with, and using them for reusable types like this feels wrong.
That said, if people want this I wouldn't want to block this PR.
|
I agree that tuple struct system params are not especially desirable -- named fields tend to be better (although this is true for tuple structs in general, it's not specific to SystemParams). Really, I see this PR as rounding out the engine by removing arbitrary limitations and places where users may experience friction. Given how prevalent anonymous tuples are in bevy, I believe most users will rightfully assume that tuple structs would just work with the derive macro. The moment when they try it and have to rewrite their type is an unfortunate toe-stub that I'd like to eliminate. |
james7132
left a comment
There was a problem hiding this comment.
Gonna agree that this shouldn't be promoted, but it removes one sharp edge from the API.
|
bors r+ |
# Objective Currently, only named structs can be used with the `SystemParam` derive macro. ## Solution Remove the restriction. Tuple structs and unit structs are now supported. --- ## Changelog + Added support for tuple structs and unit structs to the `SystemParam` derive macro.
#[derive(SystemParam)]#[derive(SystemParam)]
Currently, only named structs can be used with the `SystemParam` derive macro. Remove the restriction. Tuple structs and unit structs are now supported. --- + Added support for tuple structs and unit structs to the `SystemParam` derive macro.
# Objective * Currently, the `SystemParam` derive does not support types with const generic parameters. * If you try to use const generics, the error message is cryptic and unhelpful. * Continuation of the work started in #6867 and #6957. ## Solution Allow const generic parameters to be used with `#[derive(SystemParam)]`.
# Objective Currently, only named structs can be used with the `SystemParam` derive macro. ## Solution Remove the restriction. Tuple structs and unit structs are now supported. --- ## Changelog + Added support for tuple structs and unit structs to the `SystemParam` derive macro.
# Objective * Currently, the `SystemParam` derive does not support types with const generic parameters. * If you try to use const generics, the error message is cryptic and unhelpful. * Continuation of the work started in bevyengine#6867 and bevyengine#6957. ## Solution Allow const generic parameters to be used with `#[derive(SystemParam)]`.
# Objective Currently, only named structs can be used with the `SystemParam` derive macro. ## Solution Remove the restriction. Tuple structs and unit structs are now supported. --- ## Changelog + Added support for tuple structs and unit structs to the `SystemParam` derive macro.
# Objective * Currently, the `SystemParam` derive does not support types with const generic parameters. * If you try to use const generics, the error message is cryptic and unhelpful. * Continuation of the work started in bevyengine#6867 and bevyengine#6957. ## Solution Allow const generic parameters to be used with `#[derive(SystemParam)]`.
# Objective The `#[derive(WorldQuery)]` macro currently only supports structs with named fields. Same motivation as #6957. Remove sharp edges from the derive macro, make it just work more often. ## Solution Support tuple structs. --- ## Changelog + Added support for tuple structs to the `#[derive(WorldQuery)]` macro.
Objective
Currently, only named structs can be used with the
SystemParamderive macro.Solution
Remove the restriction. Tuple structs and unit structs are now supported.
Changelog
SystemParamderive macro.