Multiple components of the same type as separate

[Sephirothbahamut]

Quick question about having multiple components of the same type as distinct components (connected to the title of #475). Wouldn't it be straightforward to add a templated wrapper type to use in emplacing and view operations, but which gets abstracted away on access?
Something like

template <typename T, size_t index /*Just there to ensure different types are created*/>
struct component
    {
   //parameters forwarding constructor
    T data;
    }

Used like

using Speed = wrapper<Transform, 0>;
using Interpolated = wrapper<Transform, 1>;
registry.emplace<Transform>(entity);
registry.emplace<Speed>(entity);
registry.emplace<Interpolated>(entity);

auto view{registry.view<Transform, Speed, Interpolated>()};
view.each([](Transform& transform, Transform& speed, Transform& interpolated) { ... });

The idea is to make the compiler treat them as different types through a wrapper, while hiding the ".data unwrapping" away through access functions (view.each, registry.get, etcc)

Such wrapper could also have a third template parameters which when specialized defines "static constexpr auto in_place_delete = true;" on the wrapper itself, so as a bonus you get rid of polluting the actual components headers.
All that should get optimized away anyways with no performance overhead

[skypjack]

Multiple pools of the same type are supported now. Not sure what problem this wrapper solves that they don't solve already. 🤔

[Sephirothbahamut]

My bad then, I didn't find how to do that. Any google search leads at best to the issue I've linked. Where in the docs is it described? Is there an example I can refer to?

[skypjack]

Mmm yeah, probably in the doc (search for runtime types or runtime components) and in the test suite.
At the end of the day, it's about creating new pools with different names as:

auto &&transform_storage = registry.storage<Tranform>();
auto &&speed_storage = registry.storage<Tranform>("speed"_hs);
auto &&interpolated_storage = registry.storage<Tranform>("interpolated"_hs);

You can add and remove elements from these storage classes and create views with all of them then:

entt::basic_view view{transform_storage, speed_storage, interpolated_storage};

[Sephirothbahamut]

I've checked it. However I must say it feels clunky, having to manually concatenate views and get storages for each different "instance" of the same type. It looks like a great approach for scripting languages support, but brings a lot of clutter in the compile time side of the program, whereas the interface I propose would offer a lot more transparency. The size_t index template parameter in my example could be replaced with a compile time string template parameter (requires some hidden boilerplate to accept string literals as template parameters but nothing impossible).
Would you consider it an option worthy of being explored further?

[skypjack]

Would you consider it an option worthy of being explored further?

As far as I can tell, it already works out-of-the-box. You only need to add a conversion operator.
This is the version that uses hashed strings as a compile-time human-readable template parameter instead.