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