Unrelated message to this proposal to keep the records clear on my previous
discussion:
I would also like to clarify one of my earlier mistakes(2 weeks ago) where
I used std chorno as a benchmarking tool while discussing "extension to
runtime polymorphism"(that led to this proposal). Basically, the issue with
std chorno is that unlike reserved shell keywords like "time", chorno
dosent tell you the time the process took, but rather the time that
everything took while the process was running. Using shell keywords like
"time" or any other similiar tool if in windows, like sorry for doing that
unprofessional mistake and I wanted to make sure that if anyone remembers
that. Hope I didn't misguide anyone or projected a bad image of myself.

Regards, Muneem

On Sat, 18 Apr 2026, 9:41 am Muneem, <itfllow123_at_[hidden]> wrote:

> I would like to however clarify that I dropped the "tag" as a part of the
> type and now there is a new type called runtime_indexed_tuple.
>
> On Sat, 18 Apr 2026, 8:42 am Jason McKesson via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> On Fri, Apr 17, 2026 at 10:27 PM Muneem via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>> >
>> > 1. My proposal uses a tag in std namespace and since std namespace is
>> reserved, no one would be using it anyway(by defining their own tags).
>>
>> That changes nothing about what I said. None of my examples use
>> specific typenames; they're all based on template deduction, which is
>> done now.
>>
>> Look at implementations of `std::apply` and explain how it would work
>> with a tagged tuple without changing its implementation.
>>
>> > 2.i didn't meant a tag for current tuples because that's really not
>> useful, since current tuples get their element from recursion,which though
>> inefficient is efficient since it's at compile time. You will however need
>> tags or other book keeping information at some point if you were to avoid
>> such potentially inefficient recursive/looping patterns.
>>
>> From the first sentence of your proposal:
>>
>> > This proposal provides a specialization of std::tuple that can be
>> indexed at runtime.
>>
>> You're asking to make a specialization of `std::tuple`, which is
>> triggered by the use of a tag type.
>>
>> > 3. Copying a my tuple would also be trivially copyable and explicit
>> conversion to normal tuples.
>>
>> That's not possible.
>>
>> Remember how I brought up copy-on-write `std::string` implementations?
>> That kind of implementation was made possible in C++98 by very
>> particular wording around pointer/reference/iterator invalidation.
>> C++11 shut down CoW strings by taking that particular wording away.
>>
>> I bring this up because a trivially copyable type cannot have pointers
>> to itself. Well, they cannot *maintain* those pointers being pointers
>> to themselves across a copy.
>>
>> If you have a type like this:
>>
>> ```
>> struct foo
>> {
>> int i = 30;
>> int *pi = &i;
>> };
>> ```
>>
>> Value initialization for this object will leave it in a state where
>> `pi` points to the `i` member of the object. But if you copy this
>> object, the new copy's `pi` will not point to its own `i` member; it
>> will point to the copied-from object's `i` member. Same goes for
>> movement.
>>
>> In order to guarantee that the copied `pi` is a pointer to the
>> internal object's `i` member and not someone elses, you need a copy
>> constructor (and move constructor):
>>
>> ```
>> struct foo2
>> {
>> foo2(foo2 const& other) : i{other.i}, pi{&i} {}
>>
>> int i = 30;
>> int *pi = &i;
>> };
>> ```
>>
>> `foo2` is not trivially copyable.
>>
>> If `runtime_tuple` is trivially copyable, that will forbid the
>> implementation from being able to maintain pointers to its members
>> across copy/move operations. That is, if you want bookkeeping
>> information to point to its members, it *cannot* be trivially
>> copyable.
>>
>> It's one thing or the other. You cannot have both.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>