Sorry for ending it twice (I messed up while choosing the "to" part of the
email)
1.The point is that the standard shouldn't rely on users reinventing the
wheel a thousand times, each time that they want to do so.
2. The point is that sometimes you dont need to access code at fixed
points, sometimes, you want bookkeeping information. For example C++
strings employ small string optimization which again, in some cases might
be argued to cause overhead, but it serves the notion of a string well. The
only reason such optimizations can exist is because of the fact that we
aren't using C styles string everywhere, or else the compiler couldn't just
employ such optimizations. Similarly the growth of a string (according to
C++ programming language 4th edition by bjarne stroustrup) is: " To allow
Strings to efficiently ‘‘grow’’ by adding characters at the end, I
implement a scheme for keeping extra space for such growth similar to the
one used for vector (§13.6.1). This makes String a suitable target for
various forms of input. ". Similarly standard library facilities provide
predictable exceptions gurrentied as well, which is important to formalize
the notion of something that you are using in your code, so that your code
makes sense. Basically, all these facilities can only be provides if there
is a change in existing tuple implementations, and that change in code
might cause overhead in other tuples and break ABI's, hence a completely
new feature can providing whatever it wants to provide it for (in my case
runtime indexed heterogeneous lists).
3. The point on the usage of inline assembly comes from (according to C++
programming language 4th edition by bjarne stroustrup)'s section 8.2.6,
where he describes how plain old data(a notion replaced by notions about
trivial and standard layout) allows memcpy to efficiently copy data by "
block-move machine instruction ". The point is that just how the compiler
can optimize Plain old data copies, it can also perhaps copy accessing a
reference to an element if it has no compatibility with existing code to
worry about.
4. Thanks anyway for answering on Mckasson's claim on pointers.

On Fri, Apr 17, 2026 at 12:30 PM Muneem <itfllow123_at_[hidden]> wrote:

> 1.The point is that the standard shouldn't rely on users reinventing the
> wheel a thousand times, each time that they want to do so.
> 2. The point is that sometimes you dont need to access code at fixed
> points, sometimes, you want bookkeeping information. For example C++
> strings employ small string optimization which again, in some cases might
> be argued to cause overhead, but it serves the notion of a string well. The
> only reason such optimizations can exist is because of the fact that we
> aren't using C styles string everywhere, or else the compiler couldn't just
> employ such optimizations. Similarly the growth of a string (according to
> C++ programming language 4th edition by bjarne stroustrup) is: " To allow
> Strings to efficiently ‘‘grow’’ by adding characters at the end, I
> implement a scheme for keeping extra space for such growth similar to the
> one used for vector (§13.6.1). This makes String a suitable target for
> various forms of input. ". Similarly standard library facilities provide
> predictable exceptions gurrentied as well, which is important to formalize
> the notion of something that you are using in your code, so that your code
> makes sense.
> 3. The point on the usage of inline assembly comes from (according to C++
> programming language 4th edition by bjarne stroustrup)'s section 8.2.6,
> where he describes how plain old data(a notion replaced by notions about
> trivial and standard layout) allows memcpy to efficiently copy data by "
> block-move machine instruction ". The point is that just how the compiler
> can optimize Plain old data copies, it can also perhaps copy accessing a
> reference to an element if it has no compatibility with existing code to
> worry about.
> 4. Thanks anyway for answering on Mckasson's claim on pointers.
>
> On Fri, Apr 17, 2026 at 12:13 PM Jonathan Wakely <cxx_at_[hidden]> wrote:
>
>>
>>
>> On Fri, 17 Apr 2026, 05:43 Muneem via Std-Proposals, <
>> std-proposals_at_[hidden]> wrote:
>>
>>> Thanks for your feedback:
>>> > Existing tuples cannot be optimized for runtime indexing without
>>> breaking ABI (Application Binary Interface).
>>> >You responded with: Where's the evidence for it?
>>> The evidence is that without *STANDARD* support for runtime indexing,
>>> programmers will reinvent the wheel that might not always be efficient.
>>>
>>
>> OK, that's true.
>>
>>
>> To optimize such a wheel, the optimizer needs complete freedom, which it
>>> does not have because it has to maintain ABI compatibility for the
>>> components of the wheel.
>>>
>>
>> This makes no sense. The compiler doesn't need to be able to alter the
>> tuple ABI in order to optimize code accessing at fixed byte offsets.
>>
>>
>> Again, standard library defeats the user in optimizing say a container,
>>> since the container can be built with inline assembly if the implementor
>>> thinks that is efficient for that implementation,
>>>
>>
>> This is a straw man argument. No C++ implementation actually does that.
>>
>>
>> where as user written code is built on multiple blocks, where each has
>>> its own implied invariant that contributes to the semantic meaning of that
>>> block, hence it cant be optimized away by the compiler. Since, According to
>>> basic compiler theory, the optimizer can only optimize such that the
>>> semantic meaning of the code dosent change.
>>> > 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.
>>> You can't have a union of references, but however, as I said, you can
>>> have reference wrappers which are like pointers.
>>> >The main reason for this variant specialization to exist is that it
>>> cannot be valueless.
>>> Variants of references dont exist, so adding allowing references to
>>> exist in variants requires a new set of rules. Basically, a variant of
>>> const T will act differently than T, Based on the behaviour of the const
>>> type modifier. SImilarly variants of references should act differently
>>> based on how references already act. Vector of bools however does not take
>>> a completely different type, instead it takes a bool which is its own type
>>> unlike const or references for a particular type T.
>>> Many many thanks for your feedback
>>>
>>> On Fri, Apr 17, 2026 at 8:57 AM 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. So a
>>>> variant holding a union of pointers is functionally no different from
>>>> a variant holding a `void*` that it casts to the appropriate type as
>>>> needed.
>>>>
>>>> The only optimization I could see is if an implementation is able to
>>>> hide the index somewhere inside the `void*` itself, using bits in the
>>>> address that are otherwise unused. But I'm not sure that's faster than
>>>> just adding a byte before the `void*`.
>>>>
>>>> Again, if you have some evidence for this statement, put it into the
>>>> paper.
>>>>
>>>> On a different topic:
>>>>
>>>> > The main reason for this variant specialization to exist is that it
>>>> cannot be valueless.
>>>>
>>>> Specializations of a template should not radically alter the
>>>> fundamental behavior of the core template. `vector<bool>` is a bad
>>>> idea because its interface and behavior does not match what `vector`
>>>> is supposed to mean. The same goes for this `variant`; it should work
>>>> just like any other `variant`. You should be able to assign to it,
>>>> change the bound type, etc. And if it can't do those things, there
>>>> needs to be a *very* good reason as to why it doesn't.
>>>>
>>>> And feeling that valueless by exception is icky is not a good reason.
>>>>
>>>> If you don't want runtime indexing of a `tuple` to return a `variant`
>>>> that actually does what a `variant` does, then it should be a new type
>>>> with a new name.
>>>> --
>>>> 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
>>>
>>