Date: Thu, 9 Apr 2026 21:17:06 +0500
I think you can't remove the linear N space overhead without effecting
performance because then you will have to pass N-1 recursively down the
line while inheriting for the general case from some other class template,
which again, one might claim the optimizer can optimize, but I will give it
a try tomorrow. Sorry for my incomplete example though
On Thu, 9 Apr 2026, 9:04 pm Muneem, <itfllow123_at_[hidden]> wrote:
> 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
>>
>
performance because then you will have to pass N-1 recursively down the
line while inheriting for the general case from some other class template,
which again, one might claim the optimizer can optimize, but I will give it
a try tomorrow. Sorry for my incomplete example though
On Thu, 9 Apr 2026, 9:04 pm Muneem, <itfllow123_at_[hidden]> wrote:
> 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
>>
>
Received on 2026-04-09 16:17:25
