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

Simplify world schedule methods #8403

Merged
merged 12 commits into from
Apr 19, 2023
Merged

Conversation

JoJoJet
Copy link
Member

@JoJoJet JoJoJet commented Apr 16, 2023

Objective

Methods for interacting with world schedules currently have two variants: one that takes impl ScheduleLabel and one that takes &dyn ScheduleLabel. Operations such as run_schedule or schedule_scope only use the label by reference, so there is little reason to have an owned variant of these functions.

Solution

Decrease maintenance burden by merging the ref variants of these functions with the owned variants.


Changelog

  • Deprecated World::run_schedule_ref. It is now redundant, since World::run_schedule can take values by reference.

Migration Guide

The method World::run_schedule_ref has been deprecated, and will be removed in the next version of Bevy. Use run_schedule instead.

@JoJoJet JoJoJet added A-ECS Entities, components, systems, and events C-Code-Quality A section of code that is hard to understand or change C-Breaking-Change A breaking change to Bevy's public API that needs to be noted in a migration guide labels Apr 16, 2023
@JoJoJet JoJoJet requested a review from hymm April 16, 2023 13:49
@hymm
Copy link
Contributor

hymm commented Apr 17, 2023

So with the methods that take &dyn ScheduleLabel, it's very easy to end up with a boxed label that you need to remember to dereference or things will fail silently. You can see this if you go to https://github.com/bevyengine/bevy/blob/main/crates/bevy_app/src/main_schedule.rs#L146 and change the line to let _ = world.try_run_schedule_ref(label);. In this case the label is in fact double boxed.

We should remove this footgun before removing the owned variants. One potential solution is this PR #7762. But I'm unsure if that PR is the right direction.

@james7132 james7132 requested a review from cart April 18, 2023 00:44
@james7132
Copy link
Member

Roping in @cart for this since this does have some major UX implications for the API.

@JoJoJet
Copy link
Member Author

JoJoJet commented Apr 18, 2023

So with the methods that take &dyn ScheduleLabel, it's very easy to end up with a boxed label that you need to remember to dereference or things will fail silently.

Is that not also true for impl ScheduleLabel?

@JoJoJet
Copy link
Member Author

JoJoJet commented Apr 18, 2023

So the footgun does exist for impl ScheduleLabel as well; the following test fails on main:

#[test]
fn test_boxed_label() {
    use crate::{self as bevy_ecs, world::World};

    #[derive(ScheduleLabel, Debug, Default, Clone, Copy, PartialEq, Eq, Hash)]
    struct A;

    let mut world = World::new();
    world.add_schedule(Default::default(), A);
    world
        .try_run_schedule(Box::new(A) as BoxedScheduleLabel) 
        .unwrap(); // This returns `Err` since `Box::new(A) != A`
}

I agree that we should fix this footgun but I don't think this PR is affected by it.

@JoJoJet
Copy link
Member Author

JoJoJet commented Apr 18, 2023

I have a fix for the aforementioned footgun in #8436.

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.

I think this is a net improvement, but I think in this case it may be worth it to make an API that can accept either the owned form or the reference using impl Deref.

I would like to avoid the silly duplication though.

@cart
Copy link
Member

cart commented Apr 18, 2023

Operations such as run_schedule or schedule_scope only use the label by reference, so there is little reason to have an owned variant of these functions.

Having both was a UX decision. As a rule of thumb, we try to make as many user-facing label apis by-value as possible. It reads better, one less character to type, and the consistency across all label apis is nice. If someone is passing a label into a function, they can generally expect by value.

The by-ref calls are almost always going to be "bevy internals code" (ex: retrieving an existing stored label and doing something with it). Users trying to run a schedule manually should not need to worry about references. I think it is worth it to make this by-value and then have the _ref variant for the less common (generally internal) cases. Pretty much everything user-facing can (and i would assert should) use by-value.

@alice-i-cecile alice-i-cecile added the X-Controversial There is active debate or serious implications around merging this PR label Apr 19, 2023
@JoJoJet
Copy link
Member Author

JoJoJet commented Apr 19, 2023

I took @alice-i-cecile's idea and made these methods take AsRef<dyn ScheduleLabel>, so now they accept labels either by value or by reference. Also, I made this change less breaking by deprecating run_schedule_ref, which was the only one of these methods that existed in 0.10.

@alice-i-cecile
Copy link
Member

Great, I think that's a nice balance of pretty end user API and no code duplication.

Copy link
Member

@cart cart left a comment

Choose a reason for hiding this comment

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

Best of both worlds. Love it!

@cart cart added this pull request to the merge queue Apr 19, 2023
Merged via the queue into bevyengine:main with commit 9fd867a Apr 19, 2023
@JoJoJet JoJoJet deleted the no-schedule-ref-methods branch April 20, 2023 00:33
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-Breaking-Change A breaking change to Bevy's public API that needs to be noted in a migration guide C-Code-Quality A section of code that is hard to understand or change X-Controversial There is active debate or serious implications around merging this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants