1. Sorry that my first two answers weren't clear enough: in the first
answer, the tag was for partial specialization and the in the second what I
meant by tag was book keeping information.
2. I get that by allowing book keeping information, my type isn't trivially
copyable anymore, I am sorry that I didn't think about it properly, it
didn't seem significant at of me answering. I also want emphasize that
normally users want a specific runtime tuples, they don't want to think
about ways to implement it or weather's it's trivially copyable or not
because they really just don't care. If this proposal gets passed then with
variants of T&... ,You could implement other kinds of tuples but normally
you would not want to do that, normally you would want a simple way to
define and use runtime indexed tuples. My proposal provides a standard
interface for that.

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
>