-
-
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
[Merged by Bors] - [ecs] implement is_empty for queries #2271
Conversation
I wouldn't call this "Fixes #2270"; the |
Agreed, though the issue is titled |
I do have concerns that this is "yet another" complicated iterator impl. We now have 5 variants: for_each, par_for_each, iter, iter_combinations, and is_empty. Which makes logic thats already pretty hard to maintain even harder. We need to draw the line somewhere, I'm just not sure yet if its before this, or after this :) We have a couple of ways to "unify" things:
I guess as long as we add a TODO comment above this implementation calling out (2), I'm cool with this impl as an interim solution. |
TBH this is a reasonably high priority quality issue; maybe we should just try and solve this instead? |
Done. |
Yup this both significantly improves UX for query consumption (no need for both read and write queries in querysets to work around lifetime restrictions when both aliased reads and unique writes are needed) and a reduction in maintenance burden. Its just also a "relatively advanced" problem to solve as it involves both Fetch (which has lots of nuance) and advanced rust type system usage. Theres probably also multiple ways to do it, so its should have a design discussion first (maybe doesnt need an rfc, but we should survey the space). I don't see much of a reason to hold off on this, given that we can't count on a quick solve for the "harder" problem. However if someone volunteers to pick up this work immediately, I'm down to hold off on merging this. |
This is something I would love to help out with, however I can't work on it immediately as I have a bunch of other things I'm currently attending to. (It would probably be a couple weeks or so...) |
bors r+ |
## Problem - The `Query` struct does not provide an easy way to check if it is empty. - Specifically, users have to use `.iter().peekable()` or `.iter().next().is_none()` which is not very ergonomic. - Fixes: #2270 ## Solution - Implement an `is_empty` function for queries to more easily check if the query is empty.
Pull request successfully merged into main. Build succeeded: |
## Problem - The `Query` struct does not provide an easy way to check if it is empty. - Specifically, users have to use `.iter().peekable()` or `.iter().next().is_none()` which is not very ergonomic. - Fixes: bevyengine#2270 ## Solution - Implement an `is_empty` function for queries to more easily check if the query is empty.
Problem
Query
struct does not provide an easy way to check if it is empty..iter().peekable()
or.iter().next().is_none()
which is not very ergonomic.Solution
is_empty
function for queries to more easily check if the query is empty.