-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Simplify system piping and make it more flexible #8377
Simplify system piping and make it more flexible #8377
Conversation
Not quite sure what to put for the migration guide. While this is technically an API breakage, I can't image a case in which anyone would actually have their code broken to use as an example. |
I took @james7132's suggestion of merging I'm saving these changes for a follow-up so the diffs won't be horrible, as they tend to be when moving files around. |
Totally agree on both the need for reorganization and to do those in separate PRs that we merge ASAP. |
Sounds like a plan :) |
# Objective Follow-up to #8377. As the system module has been refactored, there are many types that no longer make sense to live in the files that they do: - The `IntoSystem` trait is in `function_system.rs`, even though this trait is relevant to all kinds of systems. Same for the `In<T>` type. - `PipeSystem` is now just an implementation of `CombinatorSystem`, so `system_piping.rs` no longer needs its own file. ## Solution - Move `IntoSystem`, `In<T>`, and system piping combinators & tests into the top-level `mod.rs` file for `bevy_ecs::system`. - Move `PipeSystem` into `combinator.rs`.
Objective
.pipe
on a system that takes any input other than()
.IntoPipeSystem
trait is currently very difficult to parse due to its use of generics.Solution
Remove the
IntoPipeSystem
trait, and move thepipe
method toIntoSystem
.Changelog
.pipe
on a system that takes an input.Migration Guide
The
IntoPipeSystem
trait has been removed, and thepipe
method has been moved to theIntoSystem
trait.