Ben Frankel
Ben Frankel
Not a full review yet but one note: Since `Spawn::SpawnOutput` is not given any bounds, generic contexts won't be able to do anything besides return it: ```rust fn foo(commands: C)...
Deferred vs immediate is already the case for `Commands as Spawn` vs `World as Spawn`, no?
Naming proposition: - `Spawn` -> `EntityContext` - `Spawn::SpawnOutput` -> `EntityContext::EntityBuilder` (and later this will be bound by a trait named `EntityBuilder`) Or something along these lines. Issue is, `EntityContext` can...
I'm not sure if "immediately spawns ..." is accurate to how the ECS works internally, but it's definitely not queueing a command. Open to better wording suggestions.
The `AddToApp` implementation can use `app.world_mut()` (especially the ones generated by derive macros). Systems / system sets may be a unique case (they need to be added to a particular...
Adjusted wording to better reflect that.
> you can also derive multiple insertable and addable types for a given type That's a good point. This proposal is not compatible with the same type being used to...
> How would the new super-generic API affect error messages like this? Yeah the error message would become less useful. It could ask you if you meant to derive e.g....
This may be better off reduced to an "in addition" API proposal with no auto-derived impls for `AddToApp` or `InsertToApp`. Effectively adding two new `Plugin`-like traits with different receivers (no...
Closing in favor of a smaller proposal: https://github.com/bevyengine/bevy/issues/14261.