Thanks for defending me here. Really appreciate it!

On Fri, Apr 17, 2026 at 11:51 AM Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Fri, 17 Apr 2026, 04:57 Jason McKesson via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> On Thu, Apr 16, 2026 at 10:26 PM Muneem via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>> >
>> > Abstract: This proposal provides a specialization of std::tuple that
>> can be indexed at runtime. It also introduces specializations for
>> std::variant and std::optional to ensure the interface of such a tuple
>> remains efficient.
>> > I wrote 3 files, the first was a complete draft that I am gonna paste
>> as a txt file, the second was a formatted docx file that I wanted to float
>> around the internet to get some feedback before I post it over here (sadly
>> no on was interested in the poor man's document), and the third is the
>> shortened version where I removed all the code and kept it conceptual.
>> Sorry for pasting three files at once, but I just wanted to see which one
>> is acceptable and which one isn't. Personally, I like the first two.
>>
>> Your proposal is full of key statements that you say confidently, as
>> if they were self-evidently true, but you offer no evidence for it
>> (anecdotal or otherwise). And these aren't minor nit-picks; they're
>> *foundational* to the choices your proposal makes.
>>
>> For example:
>>
>> > Existing tuples cannot be optimized for runtime indexing without
>> breaking ABI (Application Binary Interface).
>>
>> Where's the evidence for it?
>>
>> A tuple is just a struct that uses compile-time numeric indices
>> instead of compile-time names. If you use a compile-time name or
>> compile-time index, this is converted into an address within the
>> "struct". For every struct member, there is a byte offset from the
>> start of the struct to that member.
>>
>> The thing that determines what the byte offset is for a given member
>> is the implementation of the tuple/struct. This is baked into the ABI
>> of the object. Which means that the *only part* of this process that
>> is in any way ABI dependent is the specific mapping from an index to a
>> byte offset..
>>
>> Your hypothetical runtime-optimized tuple would also have a way to
>> convert an index into a byte offset. Every member would have a
>> separate byte offset. So... why would one mapping of index:byte-offset
>> be inherently slower at runtime than a different one? Why does ABI
>> matter *at all* for converting a runtime index to a byte offset?
>>
>> The veracity of your statement is the core reason why your proposal
>> uses a `tuple` specialization. That is, if this statement is untrue,
>> then there's no reason to not just allow any `tuple` to be able to use
>> runtime indexing.
>>
>> So if you're going to make that a part of your proposal, it needs to
>> actually justify this statement.
>>
>> Similarly:
>>
>> > This also means common implementations of variants (tagged unions or
>> "closed set unions") might not suffice. Instead, implementations should use
>> techniques similar to typeid or other internal mechanisms.
>>
>> Um... why not?
>>
>> A reference is just a pointer. A variant of references is really just
>> a variant of pointers. And pointers are all the same size.
>
>
> That's not guaranteed by the standard.
>
> Pointers to classes can be a different size from char*, and pointers to
> functions can be a different size too.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>