Michele Caini

Well, technically speaking it's possible already as: ```cpp for(auto [id, storage]: src_registry.storage()) { auto &&other = dst_registry.storage(storage.type()); for(auto entity: storage) { other.emplace(entity, storage.get(entity); } } ``` Morever, as I said...

🤔 Wait a moment. [This](https://github.com/skypjack/entt/blob/v3.9.0/src/entt/entity/registry.hpp#L328) is from v3.9: ```cpp [[nodiscard]] auto storage() ENTT_NOEXCEPT { return iterable_adaptor{internal::storage_proxy_iterator{pools.begin()}, internal::storage_proxy_iterator{pools.end()}}; } ``` That is, this is possible with v3.9 already: ```cpp for(auto [id,...

😲 Oh, this I don't know actually, I've always referenced the git tag. What's wrong there? The single include file or the tarball? I remember it happened one more time...

Yeah, the non-template `storage` method is only available upstream and isn't part of any release yet. The goal is to add all is needed to help creating pools across registries....

@Ramito `registry.storage()` is enough to create it.

Yeah, I want to remove the `[[nodiscard]]` in this case. I'm using it to create pools too and it's getting annoying. 😅

Mmm probably the vtable should work the other way around, that is: ```cpp registry.vtable_for(id).setup(other_registry); ``` This way you have a function with full knowledge that _triggers_ a `.storage` call on...

You're right, this is available upstream but not part of v3.9: ```cpp auto& target_store = dest.storage(source_store.type().hash()); ``` While this: > this method only works if the destination storage has already...

It turned out that this solution is waaaaaay simpler but also _incomplete_ in a sense. Something that I'll fix soon but still. Briefly, if you use meta, it's almost a...

Unfortunately, this PR is no longer valid (if we consider branch `wip` as it ought to be, that is about to be merged with `master`). Briefly, I've introduced a `registry_context`...