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).
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.
3. Copying a my tuple would also be trivially copyable and explicit
conversion to normal tuples.

On Fri, 17 Apr 2026, 9:11 pm Jason McKesson via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> One more thing: doing a tag for `std::tuple` is an implementation
> non-starter. Right now, code exists that looks something like this:
>
> ```
> template<typename Ts...>
> void func(std::tuple<Ts...> &tpl)
> {
> //Iterate over Ts...
> }
> ```
>
> This code relies on `Ts` being the sequence of types actually stored
> in `std::tuple<Ts...>`. And this code in particular relies on template
> argument deduction to allow users to just pass in a `std::tuple`.
>
> Making one of the `Ts` into a tag type breaks this code. And every
> piece of code like it (such as `std::apply`).
>
> Can it be fixed? Sure; it can check for the tag. But breaking
> everyone's code is unpleasant.
>
> Furthermore, if `Ts` are all trivially copyable, then you can assume
> that `std::tuple<Ts>` are also trivially copyable. And thus do
> trivially copyable stuff with them. But your "optimized" type doesn't
> allow for trivial copyability regardless of the `Ts`. So it breaks
> there too.
>
> Just make a new type.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>