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.