Hi!
Mr.Sebastian asked the following brilliant questions(ordering from shortest
to longest answers)
1.****** Is { a, b, c } a single object instance of one of three types or
three object instances?
Answer:
They are three objects instances:
Long answer is that just like an array, or more specifically like a
Std::vector<std::variant<Args...>>.
2.******Is the type and the selected choice which of the three known at
compile-time?
Answer:
No. infact the long answer is:
when I say the usage has the same semantics as templates, what I mean is
that that for every indexing operations, the compiler can generate any code
it wants (inline or not).
3.******Is select only choosing by type or by other information?
Answer:
Its an indexing operations: it's selects based on a integer index .


4.******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?
Answer: because the value type of the expression "list.select()" would be
something new, hence:
 it's the compilers job to generate any non member or member functions for
a call that the expression calls or is passed to. So to answer your
question:
It's totally up to the compiler just as with templates. That's why I say
it's like templates underhood because everything is left to the compiler to
decide.


5.******What in the end you get, is a common callable interface of
inheritance-wise unrelated types.

Answer: they don't have to be inheritance wise related, some you could
provide wrapper non member inlines functions. Example: for pushing into
containers, provide a wrapper that pushing back for all the containers and
front to forward list.




6.******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.
Answer: The goal is to provide new expression value types for both the set
and the elements of the set that provide the intent: Any of the elements
can be chosen at runtime, hence to produce code for that. Infact, assigning
it to a variable declared using "auto" would also lead to the compiler the
expressions that the variable is used in, in the same way. The point is
that we ourselves can do it better, but the compiler can provide a better
intermediate representation, and if we come up with a construct that's good
enough, we can maximize that advantage.

Answer 2 to the same question:My solution is to make the intent the
clearest without breaking the c++ foundation, which is by trying to propose
this new feature as an extension to templates(by giving the compiler a free
hand). The long term benefit would be a new a language level construct that
optimizes the intermediate code representation, and leads to similiar
extensions to the idea of templates.My goal isn't to argue how compiler
backends work, but to rather argue how this keyword would help intermediate
code generation because of compiler theory fundamentals clearly stating
that it's an important phase.


******Ending note******

If you think my solution isn't complete, please please please try asking
about or proposing more:
1.time and space complexity
2.compile time complexity
3.semantic requirements
4. A better syntax.



******Discussion on the last answers for your last question******:
The other proposals (reflectors and pattern marching) would still require
some design pattern in user code to address this problem. A good example
std::visit, which my bench marks(in communication with Mr. Thiago Marciena)
prove were slow. He said that we should wait for compiler backends to be
fast, but c++ shouldn't depend on compiler backends. The goal should be to
provide language constructs that optimize the code that the compiler
backend deals with. The backend cant optimize code as much as the compiler
can because it dosent have enough keywords for intent. Languages with more
words and flexible structures can have their text shortent while languages
that don't will not. C++ also has the intent of the author(the programmer)
himself. My goal isn't to argue how compiler backends work, but to rather
argue how this keyword would help intermediate code generation because of
compiler theory fundamentals clearly stating that it's an important phase.



***Why I responded late***

Sorry for my late reply, I was trying to sleep but after trying for 2 and a
halfhours with breathable a sleep mask, but I could not. my right corner of
my right eye was hurting and itching in the end, so I decided to check my
mails to do something useful, but it's as if when stuttering and having
nothing useful tod do stops being an issue, my eyes/skin become, isn't life
full of painful wonders? Keep on asking questions, I really want to keep
this discussion going, but sorry if my new response comes a few hours
later.

Regards, Muneem


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

> 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]> 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]> wrote:
>
> On Sat, Apr 4, 2026 at 6:53 AM Muneem <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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>


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

> 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]> 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]> wrote:
>
> On Sat, Apr 4, 2026 at 6:53 AM Muneem <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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>