-
-
Notifications
You must be signed in to change notification settings - Fork 4k
Closed
Labels
A-ECSEntities, components, systems, and eventsEntities, components, systems, and eventsC-BugAn unexpected or incorrect behaviorAn unexpected or incorrect behaviorD-ModestA "normal" level of difficulty; suitable for simple features or challenging fixesA "normal" level of difficulty; suitable for simple features or challenging fixesS-Needs-DesignThis issue requires design work to think about how it would best be accomplishedThis issue requires design work to think about how it would best be accomplishedX-UncontroversialThis work is generally agreed uponThis work is generally agreed upon
Description
What problem does this solve or what need does it fill?
With EntityCloner
, one can give an entity the component of another. By default the original entity keeps it's component and this operation requires the component to be clone-able.
However, if the component is moved, so the original entity loses the component, this should be no requirement. But it currently is. Move operations just fail silently
#[derive(Component)] // adding Clone or Reflect makes the assertions not fail
struct NoCloneImpl;
let mut world = World::new();
let entity1 = world.spawn_empty().id();
let entity2 = world
.spawn(NoCloneImpl)
.move_components::<NoCloneImpl>(entity1) // fails silently
.id();
assert_eq!(world.entity(entity1).contains::<NoCloneImpl>(), true); // panic
assert_eq!(world.entity(entity2).contains::<NoCloneImpl>(), false); // panic
(The same effect can be observed with EntityCloner
)
What solution would you like?
Make it possible to move components without them implementing Clone
nor Reflect
.
Additional context
This was an open todo from @eugineerd, mentioning that it is tricky to not have the component be dropped twice. I just wanted to open this issue so it is written down somewhere.
(Not sure if this is a bug issue or feature request issue)
Metadata
Metadata
Assignees
Labels
A-ECSEntities, components, systems, and eventsEntities, components, systems, and eventsC-BugAn unexpected or incorrect behaviorAn unexpected or incorrect behaviorD-ModestA "normal" level of difficulty; suitable for simple features or challenging fixesA "normal" level of difficulty; suitable for simple features or challenging fixesS-Needs-DesignThis issue requires design work to think about how it would best be accomplishedThis issue requires design work to think about how it would best be accomplishedX-UncontroversialThis work is generally agreed uponThis work is generally agreed upon