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
>