On Mon, Apr 20, 2026 at 11:20 AM Simon Schröder
<dr.simon.schroeder_at_[hidden]> wrote:
>
> On Mon, Apr 20, 2026 at 5:08 PM Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> On Mon, Apr 20, 2026 at 10:52 AM Muneem via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>> >
>> > Give me sometime to understand your code and respond. I will also write some extra possible implementations for the proposed tuple type tomorrow and run bench marks against Mine, your's, and Simon's code. I am confident mine is faster by a large margin since I can choose any implementation, which is to prove that a new type with a new implementation is good because the compiler can choose any implementation. Of this ofcourse would be just talking until I provide some numbers to back myself up.
>> >
>> > Billions thanks to everyone for their feedback.
>>
>> Note that it cannot just be faster at random access. You also have to
>> look at how much slower it is at copying, or iterating through
>> sequences of them due to the excess bloat in the type.
>
>
> This would basically make Muneem's type *not* zero overhead. Because you would pay for the overhead of bookkeeping even if you don't use operator[]. One could argue though, that one should only use Muneem's new type when wanting to access operator[] and use std::tuple in all other cases. However, this would make it unnecessarily harder if someone wants to switch later.

My main issue is having to choose. If you want runtime indexing, you
*have* to choose this size bloat. If you don't want the size bloat,
you *have* to choose no runtime indexing.

Whether there's a new type or not, the interface should still work on
a `tuple`, even if it is at reduced random access speed (though again,
there's no evidence of that yet).