I get what you are saying, but the abstract idea is the proposal in the
sense that I didn't describe much, but the issue really is that because it
is the standard library, I can't just assume things. I said all that should
be said for a standard library feature, which is that user code is normally
not as good as what the implementation can right and even if it is, even
then it's reinventing the wheel. Further more, I addressed several
questions(asked by Simon Schroeder)in my proposal that relevant to standard
specification of this facility. The point is that I tried to maintain as
much detail as the standard allows me because again, this is a standard
proposal and being abstract is important since I don't want us to go in
circles. Implementation details and assumptions always lead to some
incorrectness on all sides. Infact if you read one of the proposals for
std:: polymorphic allocator, you would see that just like I defined the
issue with user defined runtime tuples(in my proposal), I also did with the
same criticism of existing tuples. The point is that the reason, I didn't
provide information about how certain functions would look like is
precisely because the goal is to provide a new standardized interface and
many new features to make such interface efficient. If you would like to
add anything then please do, I would really appreciate your time and effort
for helping me proposal out.

On Sat, 18 Apr 2026, 3:01 pm Giuseppe D'Angelo via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> Hello,
>
> On 18/04/2026 05:04, Muneem via Std-Proposals wrote:
> > I updated my proposal:https://docs.google.com/document/d/1srd5nKI-
> > QZy0vpUdkQoD45JyKIDWhom8/edit?
> > usp=sharing&ouid=114869935649093915681&rtpof=true&sd=true <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
>
> First and foremost: this isn't a proposal. It's just an abstract idea. A
> proposal has to go in detail: discuss tradeoffs, provide a reference
> implementation, tentative wording.
>
>
> In 2.1 there's this claim:
>
> > Existing tuples cannot be optimized for runtime indexing without
> breaking the Application Binary Interface (ABI). Furthermore, switch
> statements are not guaranteed to be the fastest option for tuples with many
> elements.
>
> Could you show some data supporting this statement?
>
> Do you have a prototype implementation where you add such runtime
> `get(index)` to an existing std::tuple implementation, as well as a
> prototype implementation of the proposed runtime_index_tuple, and show
> that the new class brings significant performance gains (... that can't
> otherwise be achieved without breaking std::variant's ABI)?
>
> > This proposal introduces a specialization for std::variant<T&...> with
> the following properties:
> > No Valueless State: The variant cannot be valueless by exception.
> > Immutable Type Selection: Every std::variant<T&...> is constructed with
> a reference to a type T that it holds for its entire lifetime.
> > Assignment Logic: Assignment modifies the underlying value referred to
> by the variant rather than changing the active type.
>
> 1) These are extraordinary claims that aren't backed by extraordinary
> facts.
>
> 2) Adding support for references in std::variant deserves its own paper.
> It's something that was there originally and then removed by P0510.
>
>
> My 2 c,
> --
> Giuseppe D'Angelo
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>