Skip to content
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

Support SystemInput tuples up to 8 elements #16814

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

ItsDoot
Copy link
Contributor

@ItsDoot ItsDoot commented Dec 14, 2024

Objective

  • Writing an API, and I want to allow users to pass in extra data alongside the API provided input, and tuples are the most natural extension in this case.
  • Bring SystemInput up to par with SystemParam for tuple support.

Solution

  • Added impls for tuples up to 8 elements. If you need a 9-arity tuple or more, write your own SystemInput type (it's incredibly simple to do).

Testing

  • Added a test demonstrating this.

Showcase

Tuples of arbitrarySystemInputs are now supported:

fn by_value((In(a), In(b)): (In<usize>, In<usize>)) -> usize {
    a + b
}
fn by_mut((InMut(a), In(b)): (InMut<usize>, In<usize>)) {
    *a += b;
}

let mut world = World::new();
let mut by_value = IntoSystem::into_system(by_value);
let mut by_mut = IntoSystem::into_system(by_mut);

by_value.initialize(&mut world);
by_mut.initialize(&mut world);

assert_eq!(by_value.run((12, 24), &mut world), 36);

let mut a = 10;
let b = 5;
by_mut.run((&mut a, b), &mut world);
assert_eq!(*a, 15);

@ItsDoot ItsDoot added A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use D-Straightforward Simple bug fixes and API improvements, docs, test and examples labels Dec 14, 2024
@alice-i-cecile
Copy link
Member

@spectria-limina you were poking at this; can I get your review here?

@ItsDoot ItsDoot added the S-Needs-Review Needs reviewer attention (from anyone!) to move forward label Dec 14, 2024
@spectria-limina
Copy link
Contributor

LGTM

@@ -11,6 +13,9 @@ use crate::{bundle::Bundle, prelude::Trigger, system::System};
/// - [`InMut<T>`]: For mutable references to values
/// - [`Trigger<E, B>`]: For [`ObserverSystem`]s
/// - [`StaticSystemInput<I>`]: For arbitrary [`SystemInput`]s in generic contexts
/// - Tuples of [`SystemInput`]s up to 8 elements
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should also be documented on In.

Copy link
Contributor Author

@ItsDoot ItsDoot Dec 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In used to be the only way to pass input into systems, but given it's now just one of the multiple SystemInput types, I don't think In needs to be treated any differently from the others. I have added an extra note on all of the input types to check the trait for more information, however. I also added an example to the docs of using tuples.

Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Surprisingly simple and well-tested. I think we can probably do a bit better with docs.

Copy link
Contributor

@bushrat011899 bushrat011899 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor gripe around max tuple size documentation that isn't even specific to this PR. Otherwise, this just looks like a nice change!

#[doc(fake_variadic)]
impl_system_input_tuple,
0,
8,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a problem with this PR specifically, but I feel like Bevy should probably just have a constant somewhere for LONGEST_REASONABLE_TUPLE, instead of each site picking a somewhat random value (I think I've seen 12, 15, and 16, now also 8).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair, I just think its way less reasonable to have large-arity input tuples when even using system input at all is somewhat uncommon. So I'd prefer if we could (potentially) save some compilation time by not implementing for arities that are highly unlikely to be used in practice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Needs-Review Needs reviewer attention (from anyone!) to move forward
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants