I'm not defending you, just commenting on a claim about pointers.

On Fri, 17 Apr 2026, 07:55 Muneem via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>