1. What I meant by performance claims is a efficient interface, not a
efficient implementation. The addition of a variant of references is to
make the interface efficient.
2. The extension is to simply provide a new subscript operator and to
provide no gurrenties that the type is trivially copyable or that it is a
product type.
3. I really can't since even if I used variants of pointers, the result
would be different since unlike references, the compiler sometimes can't
assume that a pointer will point to a specific object.



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

> On 18/04/2026 17:01, Muneem via Std-Proposals wrote:
> > Again, I get your point, I really do, but the thing is that even if
> > tuples were slower:
> > 1.you would call if microbenchmarks as it always happens on the list
>
> This is a complete and utter straw man. You're making performance
> claims, so you should bring performance data.
>
>
> > 2. It dosent matter because the goal is a new type for a new notions
> > that is different that product types(tuples). Basically it tries to
> > extend the notion/idea of product types. Building anything on the top of
> > product types to extend the notion is just dragging on baggage; It's a
> > new type with new ABIs.
>
> *Which* notions? Extend *how*? Do you have a synopsis of the new type?
> Examples of usage?
>
>
>
> > 3. I can't do benchmarks since variants of references dosent exist, so
> > any benchmark would be flawed since it would not include one the main
> > aspects of what makes my proposal efficient.
>
> This is another strawman. Surely you can create a dummy/placeholder
> class to use as the return type.
>
>
> --
> Giuseppe D'Angelo
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>