That's the point, that it's messy. The code you showed also didn't solve
the main issue that you need newer mechanisms to make things faster for a
specific job. You can't make tuples store the necessary book keeping
information without breaking the ABI. In my case, I had a linear N space
overhead as a consequence of keeping some book keeping information for
dispatch and the assignment operator implementation.
Note: I forgot to instantiate the homegenous list in my main() function and
I am truly sorry for that. I wrote to code because I couldn't sleep without
trying to prove myself right. It like a relieve now that I feel like I
tried my best for today.


On Thu, 9 Apr 2026, 8:45 pm Bjorn Reese via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On 4/9/26 14:54, Muneem via Std-Proposals wrote:
>
> > The main point is that decentralized features always win because each
> > focuses on one, right now, we are using metaprogramming for everything
> > and it's a mess! (Look above!!)
>
> Simon was suggesting subscript operator for std::tuple, which less messy
> than building your own tuple type. See
>
> https://godbolt.org/z/x74E6x181
>
> Simon also suggested that std::variant should be extended to support
> references, so we can avoid copying.
>
> Having said that, I do not believe that it is a good idea to make
> std::tuple dependent on std::variant. As we have to use std::visit to
> access the data inside the std::variant anyways, I prefer an extension
> to std::visit (or a new function) that takes a visitor, a tuple-like
> object, and an index. I have posted a proof of concept for this
> elsewhere in this discussion.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>