What problem does this solve or what need does it fill?

For my reversible systems crate I want to support reversible entity commands that do structural changes.

For example, to create a reversible variant of EntityCommands::insert, that takes a Bundle as an argument, I first have to move the components that would be overwritten out of the entity so I can make this process undoable.

BundleInfo has the methods I need to get the relevant ids including required components. However, there is no further API from here on.

What solution would you like?

What would work is to move components from one entity to another by id(s). A typed variant should be added there too because it does not exist yet. This is an elegant solution because the data structure of storing untyped components is already there: The ECS storages. This might be useful for other use cases as well.

// in EntityWorldMut and EntityCommands impl

pub fn move<T: Bundle>(&mut self, to: Entity) -> &mut Self;

pub fn move_by_id(&mut self, to: Entity, component_id: ComponentId) -> &mut Self;

pub fn move_by_ids(
    &mut self, 
    to: Entity,
    component_ids: impl IntoIterator<Item = ComponentId>
) -> &mut Self;

Each variant should also come with a _with_requires variant like #15026 that has the difference to not construct required components at the target entity but to move them from the source entity as well.

Hooks should be triggered by these operations.

Panics should happen if either the source or target entity is missing or at least one ComponentId is invalid.

Open questions

• Should this come with variants like try_insert that fail silently?

What alternative(s) have you considered?

An alternative is to move the components entirely out of the ECS storage as some kind of blob. However, no such type exists yet as far I can tell. It would require extra work to design this blob, also because it needs to support generating OwningPtr for reinsertion.

I see no alternative in my untyped context. I could mirror the Bundle trait to create an associated function but that would not work with third-party Bundle implementors that do not implement my trait.

Until a feature like this comes out I consider to require only tuple bundles for my crate's API with further restrictions on the upcoming required components feature. This probably makes the API very panic-happy. 🫤

I see reflection not helping me here as not every component can be reflected.