Simplify `instantiated_t` by specializing for `std::tuple` to improve code clarity and reduce compilation time

[Kim-J-Smith]

Hi,

I noticed that instantiated_t is widely used in the codebase. The current implementation works well, but it is somewhat indirect and may introduce unnecessary compilation overhead.

Current implementation:

template <template <class...> class T, class TL, class Is, class... Args>
struct instantiated_traits;
template <template <class...> class T, class TL, std::size_t... Is,
          class... Args>
struct instantiated_traits<T, TL, std::index_sequence<Is...>, Args...>
    : std::type_identity<T<Args..., std::tuple_element_t<Is, TL>...>> {};
template <template <class...> class T, class TL, class... Args>
using instantiated_t = typename instantiated_traits<
    T, TL, std::make_index_sequence<std::tuple_size_v<TL>>, Args...>::type;

Proposed simplified implementation:

template <template <class...> class T, class TL, class... Args>
struct instantiated_traits;
template <template <class...> class T, class... Ts, class... Args>
struct instantiated_traits<T, std::tuple<Ts...>, Args...>
    : std::type_identity<T<Args..., Ts...>> {};
template <template <class...> class T, class TL, class... Args>
using instantiated_t = typename instantiated_traits<T, TL, Args...>::type;

Why this is better:

• Clearer intent – the code directly expresses "append the types from the tuple".
• Faster compilation – avoids instantiating std::make_index_sequence and repeated std::tuple_element lookups.
• Less template bloat – only one partial specialization is needed.

Important prerequisite:
The new version requires that TL is exactly std::tuple<...>. From my analysis of the current codebase, all existing uses of instantiated_t pass a std::tuple (e.g., C::overload_types, F::convention_types, etc.). So this condition holds.

Would you be open to accepting a PR that makes this change?

[mingxwa]

Hi @Kim-J-Smith,

Thanks for bringing this up.

One key detail to consider is that instantiated_t needs to remain compatible with all 'tuple-like' types (like std::pair), as defined in the Proxy specification > ProFacade requirements. Because of this, I'm opposed to a direct replacement since it would break support for those types.

What we could do instead is keep the existing implementation and add a specialization specifically for std::tuple. This would preserve compatibility while potentially speeding up the most common use cases.

Since I want to ensure we only add complexity where it provides a clear benefit, would you be interested in running some compile-time benchmarks? If you can provide some data showing a performance improvement, I'd be very glad to help you land a specialization for it!

Mingxin