I updated my proposal:
https://docs.google.com/document/d/1srd5nKI-QZy0vpUdkQoD45JyKIDWhom8/edit?usp=sharing&ouid=114869935649093915681&rtpof=true&sd=true
Thank you a lot to everyone for giving their feedback that led me to refine
my proposal


On Sat, Apr 18, 2026 at 7:38 AM Muneem <itfllow123_at_[hidden]> wrote:

> In hindsight, I think you are right, let's introduce a new type called
> "runtime_tuple". I will update my proposal as well.
>
> 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
>>
>