implement UniqueEntityArray #17954
implement UniqueEntityArray #17954
Conversation
Victoronz
added
C-Feature
|
There are also supposed to be some |
|
Gave up on that, just wrote them out manually. |
There was a problem hiding this comment.
get_manyis last of themanymethods with a missinguniquecounterpart.
It both takes and returns arrays, thus necessitates a matchingUniqueEntityArraytype!
My impression is that get_many is mainly intended to be used with two- or three-element array literals, where the syntactic overhead of converting to this type won't be worth it to save one to three integer comparisons.
It still seems fine to build this! I just don't expect a get_many_unique to actually get much use.
It is a bit of a chicken and egg type situation, it is intended to be used for low N because higher N would be quite expensive to validate. That doesn't mean that people won't want to do it, or that even using this for low N isn't worth it.
I'm not so sure about that, I've seen people ask for something like this before. The creator of |
|
Oh, interesting! I had thought the only advantage of the array version over |
Victoronz
added
S-Ready-For-Final-Review
# Objective Continuation to #16547 and #17954. The `get_many` family are the last methods on `Query`/`QueryState` for which we're still missing a `unique` version. ## Solution Offer `get_many_unique`/`get_many_unique_mut` and `get_many_unique_inner`! Their implementation is the same as `get_many`, the difference lies in their guaranteed-to-be unique inputs, meaning we never do any aliasing checks. To reduce confusion, we also rename `get_many_readonly` into `get_many_inner` and the current `get_many_inner` into `get_many_mut_inner` to clarify their purposes. ## Testing Doc examples. ## Migration Guide `get_many_inner` is now called `get_many_mut_inner`. `get_many_readonly` is now called `get_many_inner`.
# Objective Continuation of #17449. #17449 implemented the wrapper types around `IndexMap`/`Set` and co., however punted on the slice types. They are needed to support creating `EntitySetIterator`s from their slices, not just the base maps and sets. ## Solution Add the wrappers, in the same vein as #17449 and #17589 before. The `Index`/`IndexMut` implementations take up a lot of space, however they cannot be merged because we'd then get overlaps. They are simply named `Slice` to match the `indexmap` naming scheme, but this means they cannot be differentiated properly until their modules are made public, which is already a follow-up mentioned in #17954.
Objective
Continuation of #17589 and #16547.
get_manyis last of themanymethods with a missinguniquecounterpart.It both takes and returns arrays, thus necessitates a matching
UniqueEntityArraytype!Plus, some slice methods involve returning arrays, which are currently missing from
UniqueEntitySlice.Solution
Add the type, the related methods and trait impls.
Note that for this PR, we abstain from some methods/trait impls that create
&mut UniqueEntityArray, because it can be successfully mem-swapped. This can potentially invalidate a larger slice, which is the same reason we punted on some mutable slice methods in #17589. We can follow-up on all of these together in a following PR.The new
unique_arraymodule is not glob-exported, because the trait aliasunique_array::IntoIterwould conflict withunique_vec::IntoIter.The solution for this is to make the various
unique_*modules public, which I intend to do in yet another PR.