-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Add initial APIs for getting world and commands for child_builders #15416
base: main
Are you sure you want to change the base?
Add initial APIs for getting world and commands for child_builders #15416
Conversation
@benfrankel and @viridia could you take a look at this? Still quite noob at rust so it took me a bit to figure out and reason about the lifetimes properly. |
/// }); | ||
/// # } | ||
/// ``` | ||
impl<'a> ChildBuilder<'a> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
impl<'a> ChildBuilder<'a> { | |
impl ChildBuilder<'_> { |
I believe it should be possible to elide the lifetime here, and then return &mut Commands
from commands_mut
etc. with no lifetime specified.
/// }); | ||
/// } | ||
/// ``` | ||
impl<'w> WorldChildBuilder<'w> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
impl<'w> WorldChildBuilder<'w> { | |
impl WorldChildBuilder<'_> { |
Same lifetime elision.
|
||
#[test] | ||
fn get_commands_from_child_builder() { | ||
let world = World::default(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why World::default()
here and World::new()
in the other test?
let mut _world_mut_clone = world_child_builder.world_mut(); | ||
let _world_clone = world_child_builder.world(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd add explicit type annotations here, like let mut _: &mut World = ...
. Same for the .commands()
test.
} | ||
|
||
/// Same as above, except non-mutable | ||
pub fn commands(&self) -> &Commands<'a, 'a> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure there's a use-case for an immutable reference to a Commands
. I think something like this might work?
pub fn commands(&mut self) -> Commands { self.commands.reborrow() }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, I would just have the one method that returns a mutable commands.
Is there a reason we're not simply returning self.world.commands()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is a method on ChildBuilder
, there's no self.world
.
Objective
world
andworld_mut
methods toWorldChildBuilder
#15414Solution
Testing
Discussion
For those of you who asked for this, I'm trying to find a concrete use cases where these are useful? Is it because we'd be borrowing commands/world too often? I implemented this not knowing the actual use cases for this, which seemed straightforward, then when I was adding examples and what not I realized when does this actually get used?