Add systems to sets based on their world accesses

[joseph-gio]

What problem does this solve or what need does it fill?

Currently, it is difficult to order systems based only on their logical constraints. In cases where you want a system to run after (or before) other systems which access a resource or component, you need to have global knowledge of the schedule and which systems might access that data.

One example of this is for events: if you have a system that reads AppExit events, it must run after the system that sends those events -- otherwise the event will be missed forever. Ordering the systems correctly requires knowing which system sends the event and adding a dependency to it, which is difficult to discover. See #7067, which is motivated by this issue.

What solution would you like?

Make it possible to automatically assign systems to a set based on their world accesses. An event reader system with proper ordering could look like:

fn read_app_exit(mut events: EventReader<AppExit>) { ... }

app.add_system(read_app_exit.after(SendsEvents::<AppExit>::default());

When combined with #7838, transform propagation could be as simple as:

#[derive(Component)]
#[component(write_set = WriteTransform)] // any system with access to `&mut Transform` will be added to this set.
pub struct Transform { ... }

// Perform transform propagation after every system has modified `Transform`,
// and after their commands have been flushed.
app.add_system(transform_propagate_system.after_and_flush(WriteTransform));

There should be a way of manually opting out of access sets:

fn jump(q: Query<&mut Transform>) { ... }

// This system can run after `transform_propagate_system`.
app.add_system(jump.without_set(WritesTransform));

What alternative(s) have you considered?

Do nothing, and continue using global reasoning to order systems.

Additional context

A variant of this feature that is restricted to events was originally suggested in #4872.

[alice-i-cecile]

I'm in favor of this, but we need to be careful not to explode our schedule graph. These sets should be built on an as-needed basis, rather than opportunistically.

[joseph-gio]

I agree. These sets should only be added if the creator of the component or resources chooses to expose a public SystemSet for it. We don't need dozens of unused sets for every single world access.

[alice-i-cecile]

Via something like app.define_set(Reads<Transform>), which only requires type access?

Or via like... flags on the derive macro or a trait somehow, in which case it would really only be up to the owner of the component type?

[joseph-gio]

I was suggesting the latter, but I could see value in allowing outside configuration.

[alice-i-cecile]

I think I like the former better: it's annoying as a plugin author to try and predict and respond to all of the needs of your users.

I also think that in this case it will be much simpler to implement :)

[joseph-gio]

I also think that in this case it will be much simpler to implement :)

From my initial experiments, I think that the opposite is true. The derive macro approach can just build on top of System::default_system_sets, which already exists.

Making it externally configurable means creating a whole API based around access sets (need a better name for this concept), which Schedule must be aware of.

[joseph-gio]

I stand corrected -- it's actually way simpler to do it dynamically after all. Here's what I've got so far: main...JoJoJet:bevy:access-system-sets

[maniwani]

If these sets are automatically populated, they need same or nearly the same usage restrictions as SystemTypeSet.

Saying app.add_system(X.after(WritesT)) makes it more likely that things result in a DependencyCycle or SetsHaveOrderButIntersect error.

I also expect some users to mistakenly think this accounts for apply_system_buffers and mean "after all writers before next sync point" instead of "after all writers in the schedule."

Note that this implementation would need to change to use relations if/when we add them and move to systems being entities (no promises, but trying to do both for 0.11).