entt::handle with static list of allowed component types

[Lawrencemm]

I want handle to be templated on a set of component types:

entt::handle<comp1, comp2, comp3> typed_handle;

I want the handle to have the capability to get and manipulate the entity through only those types:

typed_handle.get<comp4>(); //  Compile-time error

I want handle to accept zero of these component-type arguments, in which case there is no restriction on the types it can access/modify:

entt::handle handle{registry, entity};
handle.emplace<anycomp>(entity); // Fine: no error

It seems that there might also be the possibility for an optimisation in the case of component type args being specified; the handle in this case might be like a view under the hood, storing pools that it can access directly, not having to look the pools up in the registry.

[Kerndog73]

If the entt::handle alias took a list of component types, you would have to write entt::handle<> in the case of no component types (this is a breaking change). You can still use CTAD with the entt::basic_handle class though. If you want to avoid the <>, you could leave the alias as it is and use entt::basic_handle<entt::entity, comp1, comp2, comp3>.

[skypjack]

Actually, my only concern about this is that entt::handle h has a different type than entt::hande<T, U> h and therefore I can't really write an opaque function void func(entt::handle) that works with both constrained and unconstrained handles.
Though, this is probably even desired, so that the context is explicit and part of the handle type.

[skypjack]

If the entt::handle alias took a list of component types, you would have to write entt::handle<> in the case of no component types (this is a breaking change)

Ah, damn it, that's true because handle is an alias and not a type. I completely forgot it.
So, I vote to _extend_ the handle class and introduce a different alias for constrained handles, to avoid using basic_handle with entt::entity if possible.
What about... :thinking: ... handle_span? constrained_handle? handle_dunno_gimme_a_good_idea? tied_handle? restricted_handle? Can't come up with a good name...

[Vennor]

Actually, my only concern about this is that entt::handle h has a different type than entt::hande<T, U> h and therefore I can't really write an opaque function void func(entt::handle) that works with both constrained and unconstrained handles.
Though, this is probably even desired, so that the context is explicit and part of the handle type.

Ideally it would be possible to pass an entt::handle where a entt::handle_view is expected since it's a superset. Can this be achieved currently?

[skypjack]

Uhm... Actually no, but it would be easy to do that.
I didn't think about it. Good catch.
Does the version on experimental work as expected for the other feature? I think so, but I could have missed something else.

[Vennor]

Can you update the single include please? I'll test it then.

[skypjack]

Yeah, gimme the time to polish it. 👍

[Vennor]

You probably already noticed this but I thought I'll leave a comment just in case - now that I think about it it should also be possible to pass broader restricted handles where thinner are expected, eg. provide foo(entt::handle_view<A>) with entt::handle_view<A, B>.

[skypjack]

Yeah, it should work already like that on experimental.