-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
[Merged by Bors] - Fix all_tuples macro for non-0/1 starts #4002
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
Conversation
DJMcNab
left a comment
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.
The change in itself is fine, although the motivation is unclear. I don't think we want all_tuples to be part of our public API, and obviously no internal uses run into this case.
|
Ran into it as a part of #2381, where it was explicitly used in a case where the start for the macro was set at 2 to avoid confusing duplicate cases in the API. This has since been made into an ecosystem crate (bevy_system_graph) instead of being merged into bevy_ecs, which is now as an external consumer of the macro. |
|
I just saw that Since it is useful outside of our internal use, |
The macro is used in |
|
bors r+ |
|
My preference is that we leave this public and move it to bevy_utils. I don't think it deserves its own crate. |
# Objective `all_tuples` panics when the start count is set to anything other than 0 or 1. Fix this bug. ## Solution Originally part of #2381, this PR fixes the slice indexing used by the proc macro.
# Objective `all_tuples` panics when the start count is set to anything other than 0 or 1. Fix this bug. ## Solution Originally part of bevyengine#2381, this PR fixes the slice indexing used by the proc macro.
Objective
all_tuplespanics when the start count is set to anything other than 0 or 1. Fix this bug.Solution
Originally part of #2381, this PR fixes the slice indexing used by the proc macro.