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@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals