Reading through this it seems like they're working on it. Honestly I was a
bit surprised this didn't exist in the standard library already.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0194r6.html

This is a more complex reflection library proposal, that nonetheless would
do what I need.

I'm convinced that an implementation defined type_list<base...> type would
be a better fit for this than std::tuple.

Billy

On Mon, Jan 30, 2023 at 6:06 AM Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Mon, 30 Jan 2023, 06:55 Sebastian Wittmeier via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> Some short public discussions about N2965 and its state of implementation.
>>
>>
>>
>>
>> https://stackoverflow.com/questions/18435001/what-is-the-status-of-n2965-stdbases-and-stddirect-bases
>>
>>
>> https://stackoverflow.com/questions/51320845/status-of-stdbases-and-stddirect-bases
>>
>>
>
>
> As noted in the stackoverflow comments, GCC already supports the
> intrinsics needed for this feature and libstdc++ defined the type traits
> using those intrinsics.
>
> I would expect any proposal in this space to discuss the previous
> proposals, and implementation status.
>
> I would also expect to see more discussion about std::tuple<base&...> vs
> std::tuple<type_identity<base>...> vs a dedicated type_list<base...> type.
> The considerable compile-time overhead of std::tuple<type_identity<T>...>
> could be avoided by specialising std::tuple for that case, if necessary.
> And we could even define type_list<T...> as an alias for that
> specialization.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>