Yeah, I would say, just add new templates specializations that are
implemented by the implementation in anyway it sees possible. Though
again, I think it will complicate matters but since the whole community
wants that then let's work on that.

On Sat, 11 Apr 2026, 1:58 pm Sebastian Wittmeier via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> If new member functions are added or new types are allowed as template
> parameters, one can just modify the existing ones.
>
> There is no ABI change.
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Muneem via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Sa 11.04.2026 10:16
> *Betreff:* Re: [std-proposals] Extension to runtime polymorphism proposed
> *An:* Simon Schröder <dr.simon.schroeder_at_[hidden]>;
> std-proposals_at_[hidden];
> *CC:* Muneem <itfllow123_at_[hidden]>;
> Okay, so you do need gurrentied implementation support for a
> variant<T&...> to branch into multiple std optional<T&> and no one is
> willing to make that support be taken advantage of flexibly and directly in
> the language. I will go with that then, so what should my proposal be about
> now? Should it be to extend variants by providing specialization of
> variants that only take T& and a tuple that can be runtime indexed. It is
> to be honest exactly like Mine but just uglier. So what should be the
> syntax for that invoking such specializations if variants tuples? Should it
> contain a tag such as "dynamic typing" or something like that?
> Hope you give me your feedback on this.
> Just to make sure, you do admit that we need new specializations for both,
> that have completely independent ABIs and are made from scratch so as not
> dilute the existing ones? I am happy that we got somewhere. Again thanks
> for your support and help.
>
>
> On Sat, 11 Apr 2026, 11:05 am Simon Schröder, <
> dr.simon.schroeder_at_[hidden]> wrote:
>
>
>
>
> On Apr 11, 2026, at 5:00 AM, Muneem via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> 
> Mr.thaigo did mistake my heterogeneous list with a variant, but thanks for
> reminding him for me. We all rely on community work to correct each other.
>
> My code was just an example of the limitations not the end proposal.
> Adding references to variants would dilute the idea of variants, like
> variants are supposed to be closed set duck typing mechanisms or as one
> would say it is a union with tags.
>
> First and foremost I see variants as a way to a) make unions safe and b)
> allow to store variables on the stack/in place instead of the heap. Before
> you would only create a std::vector<object*> which would mean that the
> actual objects would be allocated on the heap. Variants is a way to get rid
> of too many dynamic allocations and allows better RAII (more objects on the
> stack means fewer bugs).
>
> By adding references you are restricting the union/variant into a strict
> dynamic type that views an object.
>
> I’m not diluting any idea, I’m extending it. There is precedence that
> there is a proposal to extend std::optional to allow for references. It is
> a complicated topic, but it is how C++ standardization usually works: we
> take something that already exists and extend it if the extension is
> meaningful and valuable. Sometimes the writers of the initial proposal
> didn’t think of everything, and sometimes they purposely decided to not
> include a feature in the initial proposal to get it through standardization
> faster. And adding references to std::variant does not restrict anything:
> the user of std: variant is free to choose the existing behavior or
> references (or even mix both). Existing code would still work exactly the
> same as before. The *user* of the std::variant can restrict the variant to
> references; the standard on the other hand would extend it.
>
> The same goes to tuples, tuples are for compile time typed lists so adding
> runtime indexing will dilute the idea and probably make many existing
> documentations false.
>
> I think it is rather frustrating that we can’t use runtime indices with
> std::tuple. I bet that many have already programmed around it. Or they have
> chosen std::vector<std::variant> instead (which is definitely not the
> same). I think it is worthwhile to extend std::tuple like this (if it is
> easy to implement, which it might be now). static const member variables
> are also compile time objects. So, shouldn’t we use them at runtime because
> it dilutes the idea? Aren’t we allowed to use the output from reflection at
> runtime because reflection works at compile time? There is definitely a
> need to bridge compile time and runtime in many places. I claim there is a
> need for indexing tuple as well.
>
> For example the new defintion of what is a standard layout would suddenly
> now omit certain specializations variants from the list. Requiring
> conversions from a variant of multiple types into an optional<T&> of a
> single type will require underlying language support which again is what I
> am proposing.
>
> No, no language support required for this. Even restricting std::optional
> and std::variant to not allow references is not restricted by the language.
> Apart from the references I could easily write a conversion from
> std::variant to std::optional: use std::hold_alternative to check if the
> requested type of the optional is the current type of the variant; then
> either return this using std::get or return null nullopt. Done.
>
> The reason I don't want the underlying implementation support to be
> wrapped in standard libraries is to not dilute the existing concepts that
> already exist, and to let the support provided be freely expressed.
>
> It is not dilution of existing concepts, but extension of existing
> concepts. And the best part is that it is not only an advantage for your
> specific problem, but brings an advantage for everybody using these types.
> There will be a lot more use cases. And the changes to the standard are
> minor and can be done in separate proposals. This makes them more likely to
> be accepted. And people will understand these small changes on existing
> types easily instead of your proposal that currently nobody really
> understands. This alone makes it a better strategy to use existing types.
> (Large, complicated proposals tend to get pushed back because the committee
> cannot review _all_ proposals for the next standard.)
>
> In your case, you can't copy/move because it's wrapped in the standard
> library. In my case, it can be copied and moved, since it's not wrapped in
> anything.
>
> You are wrong: std::optional and std::variant allow copy and move. This is
> a point why I have suggested them: the user can pick himself what to do. In
> your current example implementation Element_t always points inside the list
> and it is not possible to get a copy of the underlying value. Optional and
> variant already have this built in.
>
> The issue is that at some point you will need support from the
> implementation(in your example, conversion from variants<T&...> to
> optional<T&> but would you want that support to be suppressed within the
> bounds of the interface of the facilities that you want to extend with that
> support, or do you want it to be freely expressed using the language. A
> good analogy would be:If you are getting a subway sandwich, get a healthy
> one with vinegar and multigrain instead of the "sodium packed" standard
> sandwich. The standard one is probably considered more socially acceptable
> since everyone eats it but it's also more constraint in that you can't eat
> too much of it. Same goes over here that the language one will be free to
> have its own new interface, ABI, and everything, but if the same thing is
> provided by extending the standard library then even though it is
> "standard", you can consume the support the implementation provides
> completely.
>
> You are still claiming that it is possible to invent types that are more
> efficient than std::tuple and std::variant (and maybe std::optional which I
> brought into play). It is not possible to make something more efficient
> than std::tuple which only stores its types and doesn’t need any extra
> bookkeeping because everything is known at compile time. And variant uses
> the least space possible for storage with a tag. This also cannot be
> further reduced. And optional also just has storage and a tag. All that is
> necessary if you want to be able to use these types at runtime. And—at
> least theoretically—for compile time known indices/tags the compiler could
> be able to optimize out everything.
>
>
> On Fri, 10 Apr 2026, 11:01 pm Simon Schröder via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
> On 10. Apr 2026, at 17:39, Thiago Macieira via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >
> > On Thursday, 9 April 2026 23:30:10 Pacific Daylight Time Muneem via Std-
> > Proposals wrote:
> >> template <std::size_t N, typename type_set, typename... Tail>
> >> class heterogeneous_list_impl;
> >>
> >> template <std::size_t N, typename Head_t, typename... Tail>
> >> class heterogeneous_list<N, Head_t, Tail...> : public
> >> heterogeneous_list_impl<N - 1,Element_t<N, Head_t, Tail...>,Tail...> {
> >> Head_t Element;
> >> public:
> >> using type_set = Element_t<N, Head_t, Tail...>;
> >>
> >> type_set operator[](std::size_t index) {
> >> if (index == N) {
> >> return type_set(Element);
> >> } else if constexpr (N > 0) {
> >> return this->heterogeneous_list_impl<N - 1, type_set,
> >> Tail...>::operator[](index);
> >> } else {
> >> throw std::string{"out of bound access"};
> >> }
> >> }
> >> };
> >
> > You do realise this is just std::variant with one extra operator, right?
> >
> > That operator[] could easily be implemented in the current std::variant,
> with
> > a return either of a new type such as variant_element_ref or simply
> > std::variant<std::add_reference_t<Types>...>. That return type is your
> > innovation, not the heterogeneous list type (which is not a list).
> >
> Thiago, are you now mixing up std::variant and std::tuple? To me, it looks
> like heterogeneous_list is a std::tuple and Element_t is a std::variant.
> However, Element_t has a pointer to the proper element inside the
> heterogeneous_list in Muneems example implementation; so it would be
> comparable to a std::variant that stores a reference. (Which is partially
> what you said.)
>
> I am a little bit confused by the example implementation: I fail to see
> how to actually store values inside the heterogeneous_list. Either there is
> only memory for the first element in the list or there is just a single
> list for each combination of <N,Head_t,Tail…>. I’m not really figuring this
> out by just looking at the code.
>
> Basically, this is what I’ve been saying all along: the heterogeneous list
> can be a std::tuple with an additional operator[] and the return type is a
> special instantiation of std::variant which a) can store references instead
> of just values and b) once assigned cannot change its underlying type. b)
> is easy to achieve by using const std::variant because
> std::variant::operator= is a non-const member function. We might want to
> inherit from std::variant to create a new type with a new name that
> overloads operator= to be able to assign to the currently selected
> underlying type instead of changing the selection (I guess it would be
> really confusing to just add a const overload to std::variant::operator=,
> though technically it would work).
>
> What I’m really missing from the proposed type is that it is always a
> reference to the heterogeneous list. In this way it is not possible for the
> user to choose between reference or copy. I think that this choice is
> really important. Back to a really simple example (I’m gonna use the STL
> types with features that don’t exist):
> std::tuple<int,float> list{1,0.5f}
> const std::variant<int,float> x = list[1]; // ‘1’ could also be a runtime
> value; make a copy of what is stored inside the list
> const std::variant<int&,float&> y = list[0]; // get a reference to the
> object inside the list
> const std::variant<const int&,const float&> z = list[1]; // now we have a
> reference, but cannot change the value inside the list
> It would be helpful if std::variant<Ts&…> and std::variant<const Ts&…>
> would be convertible to std::variant<Ts…> (and std::variant<Ts…> to
> std::variant<const Ts…>).
>
> Getting back to one of the previous examples:
> int^ x = list[0];
> I just noticed that this line could easily be written as
> std::optional<int&> x = list[0];
> This would allow us to write
> *x = 2;
> (if we are cocky and think we know that the optional has a value) or
> x.value() = 2; // throws if x is nullopt
>
> Sure, we could want nicer syntax than x.value(), but at least this simple
> example would work the way Muneem described it (or rather how I understood
> his description). (There was at least a proposal for std::optional<T&> at
> some point; but I’m not sure about its status.) If std::tuple::operator[]
> returns a const std::variant<Ts&…>, we might want to allow conversion from
> std::variant<Ts&…> to std::optional<T&> (where T is one of Ts…). The
> compiler can (or at least should) be able to see right through the optional
> if it knows it is not empty and optimize every access accordingly.
>
> Here is how I would try to implement operator[] for std::tuple:
> const std::variant<Ts&…> std::tuple<Ts&…>::operator[](std::size_t index)
> // also make the member function constexpr
> {
> switch(index)
> {
> case 0:
> return Ts…[0];
> break;
> case 1:
> return Ts…[1];
> break;
> default:
> std::unreachable();
> break;
> }
> }
> We cannot write this by hand for every possible instantiation of the
> tuple, but I assume it is possible to use ’template for’ to fill the switch
> automatically based on the number of entries in the tuple. This would be
> just a couple of lines of code with reflection and no template
> metaprogramming (other than just the regular std::tuple stuff we already
> have).
> Alternatively, we could write ‘return std::get<0>(*this);’ instead of
> ‘return Ts…[0];’ (I might have messed up the syntax because it is one of
> the newer features I haven’t used yet; probably needs to be a value and not
> a type).
>
> This would make the proposal a short list:
> 1. Introduce std::variant<Ts&…>
> 2. Add operator[] to std::tuple which returns const std::variant<Ts&…>
> 3. Add conversion from std::variant<Ts&…> to std::optional<T&>
> 4. Implement lots of optimizations for std::variant and std::optional (and
> std::tuple::operator[] when used at compile time)
>
> It can do (almost) anything requested. And the individual parts are not
> just for this one specific use case. Only the syntax does not look as nice.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>