[Merged by Bors] - add get_single variant #2793
Conversation
alice-i-cecile
added
A-ECS
There was a problem hiding this comment.
I like this change. In my experience, .single either works 100% of the time, or fails unrecoverably because I had a dumb error in my code that I need to fix.
Changing the default ergonomics to reflect this makes a lot of sense, and will help clarify examples.
NiklasEi
added
S-Needs-Migration-Guide
S-Ready-For-Final-Review
crates/bevy_ecs/src/system/query.rs
Outdated
| /// # use bevy_ecs::system::{Query, QuerySingleError}; | ||
| /// # use bevy_ecs::prelude::IntoSystem; | ||
| /// struct PlayerScore(i32); | ||
| /// fn player_scoring_system(query: Query<&PlayerScore>) { |
There was a problem hiding this comment.
The player scoring system would probably access the player score mutably (and it should be a resource with the current scheme)
I'm struggling to come up with a realistic example where you need read only access to a singleton entity's components. The only place I've used it is collision detection - detecting when the player collides with an obstacle.
There was a problem hiding this comment.
That is, I wonder if we should just remove the read only variants, or at least make the mutable version the default.
There was a problem hiding this comment.
I'm struggling to come up with a realistic example where you need read only access to a singleton entity's components.
There's multiple cases where I just needed the player's position - these cases certainly exist.
There was a problem hiding this comment.
I updated the example to use a Query<&Position, With<Player>> to represent a player with a position.
There was a problem hiding this comment.
I'm struggling to come up with a realistic example where you need read only access to a singleton entity's components.
I've also run into this when trying to access a camera's projection to perform math using it.
There was a problem hiding this comment.
Yeah, I was considering using an example using a Camera because that's what I used the most, but I think a player position is simple and common enough to showcase this feature.
|
I think this should snap to the same convention we use for things like |
|
bors r+ |
# Objective The vast majority of `.single()` usage I've seen is immediately followed by a `.unwrap()`. Since it seems most people use it without handling the error, I think making it easier to just get what you want fast while also having a more verbose alternative when you want to handle the error could help. ## Solution Instead of having a lot of `.unwrap()` everywhere, this PR introduces a `try_single()` variant that behaves like the current `.single()` and make the new `.single()` panic on error.
|
Build failed: |
IceSentry
force-pushed
the
try_single
branch
from
0201939
to
6b71fa6
Compare
|
bors r+ |
# Objective The vast majority of `.single()` usage I've seen is immediately followed by a `.unwrap()`. Since it seems most people use it without handling the error, I think making it easier to just get what you want fast while also having a more verbose alternative when you want to handle the error could help. ## Solution Instead of having a lot of `.unwrap()` everywhere, this PR introduces a `try_single()` variant that behaves like the current `.single()` and make the new `.single()` panic on error.
bors
bot
changed the title
Objective
The vast majority of
.single()usage I've seen is immediately followed by a.unwrap(). Since it seems most people use it without handling the error, I think making it easier to just get what you want fast while also having a more verbose alternative when you want to handle the error could help.Solution
Instead of having a lot of
.unwrap()everywhere, this PR introduces atry_single()variant that behaves like the current.single()and make the new.single()panic on error.