Thank you very very much for your feedback. I really appreciate it.

>Muneem might be misusing "AST optimisation" term. If we put together the
two
above, what he may be proposing is like what rvalue references enabled:
distinct functions that may be able to do more/different things than what
existed before. That would be a difference in the AST, because it would be a
different program altogether.
*****Answer*****
First, what I meant by "AST optimization" was gurrentied optimizations and
semantics. Semantics and gurrenties in languages should rely on syntaxtical
constructs. Especially for something that's extending polymorphism, you
need a new construct that defines semantics and optimization, so that the
compiler can look at the tree and know that this construct must be death
with this way. Rvalues have gurrenties and move semantics, and yeah, the
semantics of rvalues require a syntaxtical constructs because the semantics
are:
1. Overload may be provide for any rvalue of type T.
2. Copy elision



>However:
a) I don't know if that's the case. There's no syntax proposed.

b) even what little I understand doesn't match the problem in question of
replacing a switch

c) I don't buy that this is worth it, because without a clear explanation of
where this solution would be used, it's impossible to judge its value

The adding of even more seemingly unrelated things into the discussion, like
virtual functions, does not help understanding what the problem is. Making
imprecise statements that can be easily refuted only muddies the problem
further.
****ANSWER****
1. What's being proposed is a new expression value type that can be used as
element type of a heterogeneous list. This would allow the user to see
elements of heterogenous coming and provide overloads for them, which can
then move them, help the user reason about the code and has gurrentied. For
more information, look at this email:
https://lists.isocpp.org/std-proposals/2026/04/17639.php
2. It dosent replace std::variant or switches because it's meant to provide
new semantics as explained and new gurrenties that are different from what
switches and variants give.
3. The clear explaination is:
1. to help you as the user get a way to see elements from heterogeneous
lists coming and provide overloads for them that can't otherwise be done.
2. To provide gurrenties on this syntaxtical constructs (new expression
type) that the compiler must full fill.
4. I was trying to play all sides so I might mixed ideas which make me
sound imprecise, but that was to explain it a group as big as possible. I
didn't want to make anything concrete without feedback, so I made my
original proposal very general, and kept on narrowing it down based on
feedback.


On Sun, 5 Apr 2026, 9:04 pm Thiago Macieira via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Saturday, 4 April 2026 23:57:02 Pacific Daylight Time Simon Schröder
> via
> Std-Proposals wrote:
> > Also, rvalues (if I’m not mistaken) go down to the IR and don’t optimize
> on
> > the level of the AST. If your optimizations can only be done on the AST,
> > this is certainly a totally different thing.
> >
> > Don’t just use “guaranteed semantics” as a buzz word, but actually
> describe
> > what you want to guarantee
>
> Muneem might be misusing "AST optimisation" term. If we put together the
> two
> above, what he may be proposing is like what rvalue references enabled:
> distinct functions that may be able to do more/different things than what
> existed before. That would be a difference in the AST, because it would be
> a
> different program altogether.
>
> However:
> a) I don't know if that's the case. There's no syntax proposed.
>
> b) even what little I understand doesn't match the problem in question of
> replacing a switch
>
> c) I don't buy that this is worth it, because without a clear explanation
> of
> where this solution would be used, it's impossible to judge its value
>
> The adding of even more seemingly unrelated things into the discussion,
> like
> virtual functions, does not help understanding what the problem is. Making
> imprecise statements that can be easily refuted only muddies the problem
> further.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>