The details are important:   Is { a, b, c } a single object instance of one of three types or three object instances?   Is the type and the selected choice which of the three known at compile-time?   How are the op() provided? As the same interface within the class declarations? Additionally as a list of common operations? Do the classes have to play along or you can define everything from outside the class?   Is select only choosing by type or by other information?           What in the end you get, is a common callable interface of inheritance-wise unrelated types.   There are probably lots of existing ideas and proposals in the direction of an interface of C++ classes beyond the current abstract base classes, with which your ideas can be compared.     -----Ursprüngliche Nachricht----- Von:Muneem via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Sa 04.04.2026 09:51 Betreff:Re: [std-proposals] Extension to runtime polymorphism proposed An:Andre Kostur <andre_at_[hidden]>; std-proposals_at_[hidden]; CC:Muneem <itfllow123_at_[hidden]>; In short(the things I agree one with you gentlemen): 1.Mr. Sebastian was completely right and had a great summary. 2.I am really really sorry for the const lvalue reference part, it's wrong, and I tried to use it because I thought that if arrays decay into pointers then this should decay into const references, but not only did I term it wrong, I processed that thought wrong. 3.sorry for my verbose responses, and I completely agree that I made the mistake of being verbose.   On Sat, 4 Apr 2026, 12:45 pm Muneem, <itfllow123_at_[hidden] <mailto:itfllow123_at_[hidden]> > wrote: To reply to Adrian telling me  why making the value type const lvalue reference is wrong? I did a mistake: I was really sorry for my inconsistent usage of the term const reference type, what I meant was that it had the semantics of const reference type (but be a different type) and could decay into one, just like built in arrays can. This was a stupid mistake that I made because I thought that it's a small part of the puzzle that might useful to put just to make it look complete. What I didn't realize was that this will bite me back if not thought of consciously. I know that you chose capacity for that reason.    ***New addition*** The type of the expression of the set and the value selected would be new. I won't make any assumptions to try to make the puzzle feel complete, and I am super sorry for doing so. On Sat, 4 Apr 2026, 12:35 pm Andre Kostur, <andre_at_[hidden] <mailto:andre_at_[hidden]> > wrote: On Sat, Apr 4, 2026 at 6:53 AM Muneem <itfllow123_at_[hidden] <mailto:itfllow123_at_[hidden]> > wrote: > > Sorry for the late reply( I was showering and using hair oil) > Sorry for my confusing reply, really sorry. > The short answer is: > NO > The long answer is: > The rules for templates would apply here, and concepts can be used to further constraint the requirements and make any resulting errors readable, so basically, it would work only if vector and list have the member capacity. That's why I chose capacity(), it doesn't exist in one of the types. So you're suggesting that the compile would have to try the syntax against every type in the set? This answer seems inconsistent with one of your previous answers regarding the type of 'x': "The answer is the *********const reference type********* of the object at the index read' (ignoring the const part).  If the type of x is std::vector<int>, then there should be no reason to fail to compile a call to capacity(). -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals