What problem does this solve or what need does it fill?
Certain algorithms require a guarantee that the entities in a RelationshipTarget are unique for performant and correct behavior. Specifically this is required for transform propagation, which I am looking to have support user-defined relationships in #25468.
What solution would you like?
RelationshipTarget::Collection::SourceIter should be required to implement EntitySetIterator. With this change Vec<Entity> could not be used as RelationshipTarget::Collection anymore as safe user code edit it to contain duplicates, causing undefined behavior. This is currently the case for Children, and is already causing undefined behavior as seen here #25349. We would need a Vec that prevents duplicates, or use other collections such as EntityIndexSet, see #23296.
What alternative(s) have you considered?
We could add a UniqueRelationshipTarget supertrait that is implemented for every RelationshipTarget which fulfills the requirement above. This way non-unique relationships would still be possible, though I am not aware of a use case for those.
What problem does this solve or what need does it fill?
Certain algorithms require a guarantee that the entities in a
RelationshipTargetare unique for performant and correct behavior. Specifically this is required for transform propagation, which I am looking to have support user-defined relationships in #25468.What solution would you like?
RelationshipTarget::Collection::SourceItershould be required to implementEntitySetIterator. With this changeVec<Entity>could not be used asRelationshipTarget::Collectionanymore as safe user code edit it to contain duplicates, causing undefined behavior. This is currently the case forChildren, and is already causing undefined behavior as seen here #25349. We would need a Vec that prevents duplicates, or use other collections such asEntityIndexSet, see #23296.What alternative(s) have you considered?
We could add a
UniqueRelationshipTargetsupertrait that is implemented for everyRelationshipTargetwhich fulfills the requirement above. This way non-unique relationships would still be possible, though I am not aware of a use case for those.