[Merged by Bors] - Auto-label function systems with SystemTypeIdLabel #4224

cart · 2022-03-16T00:42:03Z

This adds the concept of "default labels" for systems (currently scoped to "parallel systems", but this could just as easily be implemented for "exclusive systems"). Function systems now include their function's SystemTypeIdLabel by default.

This enables the following patterns:

// ordering two systems without manually defining labels
app
  .add_system(update_velocity)
  .add_system(movement.after(update_velocity))

// ordering sets of systems without manually defining labels
app
  .add_system(foo)
  .add_system_set(
    SystemSet::new()
      .after(foo)
      .with_system(bar)
      .with_system(baz)
  )

Fixes: #4219
Related to: #4220

Credit to @aevyrie @alice-i-cecile @DJMcNab (and probably others) for proposing (and supporting) this idea about a year ago. I was a big dummy that both shut down this (very good) idea and then forgot I did that. Sorry. You all were right!

cart · 2022-03-16T00:43:13Z

Note that I implemented this because it was "very easy", not necessarily because I'm voting for it as the final solution.

alice-i-cecile · 2022-03-16T00:46:55Z

(currently scoped to "parallel systems", but this could just as easily be implemented for "exclusive systems").

IMO this isn't worth our time; we should pursue #4166 instead.

But that would require adapting before() and after() to accept that trait (and implementing the trait for all SystemLabels).
Definitely worth considering. But its a lot of extra complexity.

IMO this is worth doing, but maybe not right now. The ergonomics win is quite significant here.

.label() would conflict with system_b.label(MyCustomLabel). We can (and should) discuss renaming this to system_b.with_label(MyCustomLabel) to free up the system_a.after(system_b.label(()).

I don't think either usage is clearer, and I'd prefer to a) avoid breaking user code and b) pursue the .system_label-yeet solution above.

cart · 2022-03-16T00:51:58Z

IMO this is worth doing, but maybe not right now. The ergonomics win is quite significant here.

I'll give it a try

cart · 2022-03-16T01:08:06Z

That works! Only outstanding issue is one of our tests failing because the test checks the "first labels" of ambiguous systems (which are now the default labels) instead of checking the manual "string labels" that were assigned.

cart · 2022-03-16T01:09:10Z

Updated the description to account for the better ergonomics.

cart · 2022-03-16T01:12:20Z

Biggest downside is that before(system_name) will monomorphize its impls for every unique system function signature passed in. But its a relatively small function and you only pay for what you actually use. And its a "lateral move" for custom labels, which already behaved that way. And it should be an identical compile time cost when compared to per-system-custom-labels.

cart · 2022-03-16T01:21:52Z

Alrighty I fixed the ambiguity test. Now that the UX downsides have been eliminated, I think I'm ready to vote to merge this. Its a big (non-breaking) ergo win for almost zero effort. Future "owned ordering" SystemGraph-like solutions are still on the table, even if we merge this.

alice-i-cecile · 2022-03-16T02:08:30Z

We should update the SystemLabel docs to reflect this change; I think that's the best location for it.

cart · 2022-03-16T02:19:41Z

Makes sense. Also forgot to call out a corner case of this impl: closure systems. They will be labeled with an anonymous TypeId that can only be retrieved if you have an instance of the closure. This feels very reasonable to me. You can either retrieve the SystemTypeIdLabel from the instance and pass it around, or you can create a new custom label and manually apply it.

james7132 · 2022-03-16T02:22:51Z

crates/bevy_ecs/src/system/function_system.rs

@@ -489,3 +506,21 @@ macro_rules! impl_system_function {
 }

 all_tuples!(impl_system_function, 0, 16, F);
+
+pub trait AsSystemLabel<Marker> {


Please add a short doc comment stating this is used for system -> SystemLabel coercion plus a pointer to SystemLabel which illustrates the ergonomics.

It'd also stave off the perpetually missing #[forbid(missing_docs)] for the crate.

crates/bevy_ecs/src/system/function_system.rs

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

DJMcNab

Broadly in favour. I'd rather AsSystemLabel consumed and wasn't a method, but don't block on that.

crates/bevy_ecs/src/schedule/stage.rs

crates/bevy_ecs/src/schedule/system_descriptor.rs

DJMcNab · 2022-03-16T07:26:59Z

crates/bevy_ecs/src/system/function_system.rs

@@ -489,3 +507,21 @@ macro_rules! impl_system_function {
 }

 all_tuples!(impl_system_function, 0, 16, F);
+
+pub trait AsSystemLabel<Marker> {
+    fn as_system_label(&self) -> Box<dyn SystemLabel>;


Suggested change

fn as_system_label(&self) -> Box<dyn SystemLabel>;

fn as_system_label(this: &Self) -> Box<dyn SystemLabel>;

I don't think we need this to be a method, for similar reasons we don't need the analagous IntoSystem::into_system as a method.

Idk if "non method Self functions" is a pattern I want to encourage generally. We had a good reason to do that for IntoSystem: deprecating .system() let us "encourage" users to use the more ergonomic pattern without outright breaking their code. We don't have that context here. Given that methods are the more common pattern, I think the more relevant question is: why not make this a method?

Mostly it's never meant to be used by end users, but will clutter up the flyimport suggests when users are attempting to find .before or .after, especially as alphabetically it is in between those two options.

Cluttering auto-complete imports is actually a compelling argument here :)

Mostly it's never meant to be used by end users,

I'm not sure I agree, given that getting the "closure" label is something you'd want to do with an as_system_label call (which would benefit from method-style syntax). Other use cases may emerge in the future too (ex: if something needs to accept a list of labels, we can't pass a bunch of different AsSystemLabel impls ... we need to convert to boxed labels before the call).

I personally don't think autocomplete is much of an issue here, as I think most people type at least the first letter of what they're looking for in autocomplete. .b for .before, .a for .after ... .after comes before .as in an alphabetically sorted list.

I personally don't think autocomplete is much of an issue here, as I think most people type at least the first letter of what they're looking for in autocomplete. .b for .before, .a for .after ... .after comes before .as in an alphabetically sorted list.

Fair enough.

DJMcNab · 2022-03-16T07:28:07Z

crates/bevy_ecs/src/system/function_system.rs

+
+impl<T: SystemLabel> AsSystemLabel<()> for T {
+    fn as_system_label(&self) -> Box<dyn SystemLabel> {
+        self.dyn_clone()


The need to clone here is an unfortunate 'regression'

Is there any downside to just making AsSystemLabel consume self?

Consuming self would make this unusable for closure systems, as retrieving the label would consume the IntoSystem impl (aka the closure).

Note that this doesn't add extra boxing (this replaces the manual boxing that we did in the past). Given that basically all system labels are enums, typeids, or ZSTs, the extra clone probably wouldn't even be measurable, even for many thousands of systems.

It's already hugely unergonomic for closure systems though. Either you create the 'same' closure twice:

fn my_closure_system() -> ... {||{}} app.with_system(my_closure_system()).with_system(other.after(my_closure_system()))

Or you store it in a local variable:

let closure = || {}; with_system(other.after(&closure)).with_system(closure) // has to be this order.

But yeah, perhaps being able to use the second pattern is worthwhile.

IMO this is so challenging (and niche) for closure systems that we shouldn't go out of our way to support it. Providing an explicit label is a nice clear workaround.

This seems like a really reasonable use case / pattern for closure systems. Given that closure systems are now "the" way to pass in-scope configuration into a system, and closures will also exist in that scope, I think its reasonable to support ordering without needing to define custom labels. At the very least, I think this should be possible (and it currently is):

let closure = || {}; app .add_system(foo.after(closure.as_system_label()))) .add_system(closure)

But I'm also open to making @DJMcNab's second suggestion work.

I just made AsSystemLabel return the actual label type instead of a box. This doesn't "resolve" the extra clone, but it does feel like a cleaner design to me. I really don't think this should consume self, as I don't think we should commit to all system instances being "disposable". "closure systems" already aren't disposable, and things like the current manual FixedTimestep system implementation also "hold state" and shouldn't be disposed of here (I know that the FixedTimestep impl is controversial, but its illustrative of the "custom system" pattern). I stand by the thought that an extra clone here won't hurt anyone, especially when labels are basically exclusively ZSTs and enums.

superdump · 2022-03-16T09:13:49Z

What do the resulting system labels look like? Do they have a string form? How do they look in tracing spans? And do these automatic labels work well for things like ExtractComponentPlugin’s extraction system?

cart · 2022-03-19T03:28:15Z

What do the resulting system labels look like?

SystemTypeIdLabel(TypeId), where TypeId is a u64 hash.

Do they have a string form?

They could, if we're willing to also store the type_name in the SystemTypeIdLabel (or if the "hash" is acceptable).

How do they look in tracing spans?

We don't put system labels in tracing spans atm.

And do these automatic labels work well for things like ExtractComponentPlugin’s extraction system?

Now that #3817 is merged, that extract system is a "function system" so in theory it works. However currently that is a private system. If we want to treat that as part of our public api / let people make their systems depend on it, we can make the system pub.

james7132 · 2022-03-19T04:23:40Z

Do they have a string form?

They could, if we're willing to also store the type_name in the SystemTypeIdLabel (or if the "hash" is acceptable).

Could we not do the following?

#[derive(SystemLabel, ...)]
pub struct SystemLabelId<T: 'static> {
  marker_: PhantomData<T>,
}

Then when implementing Hash, Debug, etc. we use TypeId::of<T> and TypeId::type_name<T>? This would make the type a ZST and still provide type data for debugging. Downside is the additional compile time needed for each system, though if it transparently uses the Debug and Hash implementations of TypeId, a bunch of those impls would be flattened out or combined during compilation.

james7132 · 2022-03-19T04:32:15Z

crates/bevy_ecs/src/system/function_system.rs

+
+#[derive(Debug, Hash, PartialEq, Eq, Copy, Clone)]
+/// A [`SystemLabel`] that was automatically generated for a system on the basis of its `TypeId`.
+pub struct SystemTypeIdLabel(pub(crate) TypeId);


Suggested change

pub struct SystemTypeIdLabel(pub(crate) TypeId);

pub(crate) struct SystemTypeIdLabel(pub(crate) TypeId);

Or if we can afford it, remove the pub entirely.

Like #4250. This is more of an implementation detail than anything else, probably shouldn't made public.

Imo this label is a part of our public api (especially with my recent changes, which remove the box from AsSystemLabel). I think there might be cases where this should be accessible to users.

cart · 2022-03-23T01:19:13Z

Just pushed changes that remove the boxing from AsSystemLabel, which feels less "hackey" to me. Also made SystemTypeIdLabel a ZST, per @james7132's suggestion.

Barring further feedback, I think I'll merge this.

DJMcNab

Nothing blocking.

crates/bevy_ecs/src/schedule/stage.rs

DJMcNab · 2022-03-23T10:00:19Z

crates/bevy_ecs/src/system/function_system.rs

+/// "system functions" to their [`SystemTypeIdLabel`].
+pub trait AsSystemLabel<Marker> {
+    type SystemLabel: SystemLabel;
+    fn as_system_label(&self) -> Self::SystemLabel;


I'll record that I'm still not super happy with this being a method, but I don't think that's changing.

Yeah I'm not (yet) convinced. I think there are good reasons to make "manually retrieving the label from a system instance" a part of our api. We don't abstract out "other" labels and we let those instances float around. Why abstract out these?
I'm down to continue discussing, but I dont want to block on this.

DJMcNab · 2022-03-23T10:01:59Z

crates/bevy_ecs/src/system/function_system.rs

+}
+
+/// A [`SystemLabel`] that was automatically generated for a system on the basis of its `TypeId`.
+pub struct SystemTypeIdLabel<T: 'static>(PhantomData<fn() -> T>);


This couldn't be derive(Default) because of the type parameter bounds, but should it still be Default?

Interesting. This would enable people to construct these labels without an instance to a system type. Maybe thats good. Is there a use case?

Interesting. This would enable people to construct these labels without an instance to a system type. Maybe thats good. Is there a use case?

This could be useful if you wanted to initialize an array of these things, especially if we also impl'd Copy. I'm not immediately sure why you'd want to do that though.

Haha I'm impatient, so I'm just going to merge this now. I'm happy to add this if we decide its needed.

crates/bevy_ecs/src/system/system.rs

examples/ecs/system_sets.rs

cart · 2022-03-23T22:53:40Z

bors r+

@aevyrie

This adds the concept of "default labels" for systems (currently scoped to "parallel systems", but this could just as easily be implemented for "exclusive systems"). Function systems now include their function's `SystemTypeIdLabel` by default. This enables the following patterns: ```rust // ordering two systems without manually defining labels app .add_system(update_velocity) .add_system(movement.after(update_velocity)) // ordering sets of systems without manually defining labels app .add_system(foo) .add_system_set( SystemSet::new() .after(foo) .with_system(bar) .with_system(baz) ) ``` Fixes: #4219 Related to: #4220 Credit to @aevyrie @alice-i-cecile @DJMcNab (and probably others) for proposing (and supporting) this idea about a year ago. I was a big dummy that both shut down this (very good) idea and then forgot I did that. Sorry. You all were right!

bors · 2022-03-23T23:10:57Z

Pull request successfully merged into main.

Build succeeded:

# Objective - Since #4224, using labels which only refer to one system doesn't make sense. ## Solution - Remove some of those. ## Future work - We should remove the ability to use strings as system labels entirely. I haven't in this PR because there are tests which use this, and that's a lot of code to change. - The only use cases for labels are either intra-crate, which use #4224, or inter-crate, which should either use #4224 or explicit types. Neither of those should use strings.

@aevyrie

This adds the concept of "default labels" for systems (currently scoped to "parallel systems", but this could just as easily be implemented for "exclusive systems"). Function systems now include their function's `SystemTypeIdLabel` by default. This enables the following patterns: ```rust // ordering two systems without manually defining labels app .add_system(update_velocity) .add_system(movement.after(update_velocity)) // ordering sets of systems without manually defining labels app .add_system(foo) .add_system_set( SystemSet::new() .after(foo) .with_system(bar) .with_system(baz) ) ``` Fixes: bevyengine#4219 Related to: bevyengine#4220 Credit to @aevyrie @alice-i-cecile @DJMcNab (and probably others) for proposing (and supporting) this idea about a year ago. I was a big dummy that both shut down this (very good) idea and then forgot I did that. Sorry. You all were right!

# Objective - Since bevyengine#4224, using labels which only refer to one system doesn't make sense. ## Solution - Remove some of those. ## Future work - We should remove the ability to use strings as system labels entirely. I haven't in this PR because there are tests which use this, and that's a lot of code to change. - The only use cases for labels are either intra-crate, which use bevyengine#4224, or inter-crate, which should either use bevyengine#4224 or explicit types. Neither of those should use strings.

# Objective Fix #5653. ## Solution - Add an example of how systems can be ordered from within a stage. - Update some docs from before #4224

# Objective Fix bevyengine#5653. ## Solution - Add an example of how systems can be ordered from within a stage. - Update some docs from before bevyengine#4224

@aevyrie

This adds the concept of "default labels" for systems (currently scoped to "parallel systems", but this could just as easily be implemented for "exclusive systems"). Function systems now include their function's `SystemTypeIdLabel` by default. This enables the following patterns: ```rust // ordering two systems without manually defining labels app .add_system(update_velocity) .add_system(movement.after(update_velocity)) // ordering sets of systems without manually defining labels app .add_system(foo) .add_system_set( SystemSet::new() .after(foo) .with_system(bar) .with_system(baz) ) ``` Fixes: bevyengine#4219 Related to: bevyengine#4220 Credit to @aevyrie @alice-i-cecile @DJMcNab (and probably others) for proposing (and supporting) this idea about a year ago. I was a big dummy that both shut down this (very good) idea and then forgot I did that. Sorry. You all were right!

# Objective - Since bevyengine#4224, using labels which only refer to one system doesn't make sense. ## Solution - Remove some of those. ## Future work - We should remove the ability to use strings as system labels entirely. I haven't in this PR because there are tests which use this, and that's a lot of code to change. - The only use cases for labels are either intra-crate, which use bevyengine#4224, or inter-crate, which should either use bevyengine#4224 or explicit types. Neither of those should use strings.

Auto-label function systems

e8a5c6a

cart added A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use labels Mar 16, 2022

github-actions bot added the S-Needs-Triage This issue needs to be labelled label Mar 16, 2022

alice-i-cecile removed the S-Needs-Triage This issue needs to be labelled label Mar 16, 2022

a.after(b)

649987b

fix ambiguity test

76ca7f6

james7132 requested changes Mar 16, 2022

View reviewed changes

alice-i-cecile mentioned this pull request Mar 16, 2022

As soon as possible and as late as possible system ordering #4173

Closed

alice-i-cecile reviewed Mar 16, 2022

View reviewed changes

crates/bevy_ecs/src/system/function_system.rs Outdated Show resolved Hide resolved

Update crates/bevy_ecs/src/system/function_system.rs

a964e8e

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

DJMcNab approved these changes Mar 16, 2022

View reviewed changes

james7132 reviewed Mar 19, 2022

View reviewed changes

alice-i-cecile added this to the Bevy 0.7 milestone Mar 20, 2022

Make SystemTypeIdLabel ZST, remove boxing from AsSystemLabel

ca7c674

clippy

c39276e

DJMcNab approved these changes Mar 23, 2022

View reviewed changes

bors bot changed the title ~~Auto-label function systems with SystemTypeIdLabel~~ [Merged by Bors] - Auto-label function systems with SystemTypeIdLabel Mar 23, 2022

bors bot closed this Mar 23, 2022

DJMcNab mentioned this pull request Mar 26, 2022

[Merged by Bors] - Remove unnecessary system labels #4340

Closed

mockersf mentioned this pull request Mar 27, 2022

[Merged by Bors] - Use storage buffers for clustered forward point lights #3989

Closed

alice-i-cecile mentioned this pull request Mar 28, 2022

Improvements to execution order ambiguity reporting #4299

Closed

4 tasks

R3DP1XL mentioned this pull request Mar 31, 2022

integrated PR #4224 from Bevy legion-labs/legion#1348

Merged

alice-i-cecile mentioned this pull request Apr 4, 2022

Remove the ability to use strings as labels #4409

Closed

2 tasks

JoJoJet mentioned this pull request Dec 24, 2022

[Merged by Bors] - Add a basic example for system ordering #7017

Closed

bors bot pushed a commit that referenced this pull request Dec 25, 2022

Add a basic example for system ordering (#7017)

a832582

# Objective Fix #5653. ## Solution - Add an example of how systems can be ordered from within a stage. - Update some docs from before #4224

bors bot pushed a commit that referenced this pull request Dec 25, 2022

Add a basic example for system ordering (#7017)

a91f89d

# Objective Fix #5653. ## Solution - Add an example of how systems can be ordered from within a stage. - Update some docs from before #4224

	fn as_system_label(&self) -> Box<dyn SystemLabel>;
	fn as_system_label(this: &Self) -> Box<dyn SystemLabel>;

	pub struct SystemTypeIdLabel(pub(crate) TypeId);
	pub(crate) struct SystemTypeIdLabel(pub(crate) TypeId);

[Merged by Bors] - Auto-label function systems with SystemTypeIdLabel #4224

[Merged by Bors] - Auto-label function systems with SystemTypeIdLabel #4224

Conversation

cart commented Mar 16, 2022 • edited Loading

cart commented Mar 16, 2022

alice-i-cecile commented Mar 16, 2022

cart commented Mar 16, 2022

cart commented Mar 16, 2022

cart commented Mar 16, 2022

cart commented Mar 16, 2022 • edited Loading

cart commented Mar 16, 2022

alice-i-cecile commented Mar 16, 2022

cart commented Mar 16, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DJMcNab left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

superdump commented Mar 16, 2022

cart commented Mar 19, 2022 • edited Loading

james7132 commented Mar 19, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cart commented Mar 23, 2022

DJMcNab left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cart Mar 23, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cart commented Mar 23, 2022

bors bot commented Mar 23, 2022

cart commented Mar 16, 2022 •

edited

Loading

cart commented Mar 16, 2022 •

edited

Loading

cart commented Mar 16, 2022 •

edited

Loading

cart commented Mar 19, 2022 •

edited

Loading

james7132 commented Mar 19, 2022 •

edited

Loading

cart Mar 23, 2022 •

edited

Loading