#[derive(Clone)] on Component{Info,Descriptor}

[SludgePhD]

Objective

Occasionally, it is useful to pull ComponentInfo or ComponentDescriptor out of the Components collection so that they can be inspected without borrowing the whole World.

Solution

Make ComponentInfo and ComponentDescriptor Clone, so that reflection-heavy code can store them in a side table.

---

Changelog

• Implement Clone for ComponentInfo and ComponentDescriptor

[james7132]

This likely isn't too big of an issue, but a lot of the type safety and soundness of the ECS is heavily reliant on these being correct. We currently do not expose a way to mutably accesss these from Components, but a lot of care should be taken to ensure that the ability to clone them doesn't cause any potential safety footguns, both internally and externally.

I'll give this a more thorough sweep later.

[hymm]

My one worry is the drop function stored on ComponentDescriptor. But you'd need to have an owned OwningPtr to even call it and it's already unsafe, so it's probably ok to give access to it.

[SludgePhD]

Yeah, and you already had access before, this just lets you have owned access without having to borrow the Components.

[nicopap]

As mentioned, the only worry is the drop function, otherwise this is perfectly fine, and I personally thought I needed this a couple times.

[james7132]

We don't expose a &mut Component{Info,Descriptor} of any kind, and this does not change the status quo.

This does re-raise the old concerns I had with @maniwani's "components as entities" idea, however. Not sure if they have any comments on this change.

[maniwani]

This does re-raise the old concerns I had with @maniwani's "components as entities" idea, however.
Not sure if they have any comments on this change.

I don't see an issue. The only thing that would raise safety concerns is the user being able to modify the data in Components, but that isn't the case here (it's also not the case in making components entities btw).

[james7132]

OK sounds good to me then. Merging.