I am fine, it's just my nasty eye infection that keeps me from sleeping or
having tears, thanks for caring ❤️❤️❤️.
*****Short answer*****
1.The reason, I don't have to prove anything is because compilers already
use a value type very similar to mine:
 rvalue references to give gurrentied *semantics*. I am claiming that
rvalues are faster, but rather they have guaranteed semantics (move
semantics( that the user can provide constructors and assignments for)),
optimizations, and overload functions based on rvalue references
2 the reason my construct is suppose to fast at and abstract tree level is
the same reason as for rvalues that rvalues are in the abstract tree, they
give out intent that this xvalues is trying to be moved or give or prvalue
to be construct in place because of optimization gurrentied.

> Std::visit is proven to be slow in my discussion with mr.thiago, who said
> that we should wait for compiler backends to become faster, which is
> irrelevant because c++ is supposed to have constructs that make it fast on
> an intermediate representation level. It can't even be optimized on an
> abstract tree level and/or dosent provide std::move(variant_obj)
>No, we have proven that the difference in performance is negligible and
therefore not an argument.
********Answer*******: The reason that I said that you proved me is because
the compiler was better at optimizing things that do nothing for constructs
like switch case than std::visit (recall the loop that was folded in half
for switch but visit), and that was my point that relying on making visit
faster is wrong and tedious. Why does it matter to optimize code that does
nothing? Normally code is to make code coherent and look good, say this:
Int input= take_input<a lot of template arguments>(a lot arguments);
Int b =input +1;
Here input is to make the code readable.
So optimizing code that does nothing is actually useful. If you admitted
then that shows that std visit has a weak point.
****How does my construct fix this*****
My construct is like rvalues(as I said), it has its own semantics and
gurrenties, so optimizing away code is more easier because semantical
gurrenties, in particular, optimizing code that does nothing is easier
because it's right in the abstract tree. Like you can look at the abstract
if a switch statement and ask if you should optimize it away or not, but
for std visit, there is no abstract tree, no gurrenties semantics, no way
for the user to provide overloads for std::variant objects.


> The compilers can do optimizations on abstract tree level, but without
> significant overhead, it can't do those on std::visit. At least not to
> counter the fact that move semantics are missing(constructs can't be
> virtual).

Unproven statement again.
****Answer*****
Gurrantied rvalue optimizations and rvalue semantics beg to differ. take a
look at the abstract tree of a program using rvalues, and see if it's easy
for you to optimize that instead of the same one using lvalues. Even if say
backends were to do so, then rvalues still help reason and feel safe.

And "constructs can't be virtual" is a meaningless statement. std::visit has
nothing to do with virtual calls: it can be used to call virtual functions.
Moreover, the implementation of the visitation can choose to use a jump
table,
either by doing it manually like it looks like libc++ does, or by having the
compiler implement it via sequence of if-else chain.
****Answer****
I said constructors can't be virtual, as a response to mr.steve. I am
trying to play all sides by answering that it works for everyone, but
sometimes it backfires. Like not everyone agrees with everything. Mr.simon
says compile times matter, you said they don't, but I try to say that
gurrentied semantics play all sides.

As I said, a new expression value type is better because it plays all
sides, and helps you optimize through user defined operations (that may
have smaller function bodies(in theory confirmed lower compile time) or
more efficient code in them). It can also help gurrentied certain
optimizations like rvalues do using copy elision.


> Your example shows that I mean, compilers convert them into switch case
> statements on a assembly level, not on a abstract tree level. We need a
new
> value type to change the value abstract trees work.

>Unsubstatiated statements. Why do you think we need a new value type to
inform
the AST? Why aren't the current techniques sufficient? What information,
specifically, would compilers readily have available to improve on code
generation that they don't today?
******answer******
1. let's get back to the basics: expression values types:
Glvalues and rvalues:
Glvalues have xvalues and lvalues
While rvalues have xvalues and prvalues
On an abstract tree level, these expression value types matter to allow
overloading, gurrentied optimizations(copy eliding), and move semantics.
2.This new value that I am propose would give similar gurranties,
semantics, for the user to overload using this value type, and last but not
least, as I said before, it would provide the compiler an opportunity to
optimize code that is doing nothing but exists for readability/style
purposes. This is something that all of us do.
3. Just how the current expression values help us reason, the new one will
also help us look at our code and reason about indexing elements in
heterogeneous lists better. Again, look at how rvalues make us reason.

******answer******







You have not shown the widespread problem you claim exists and more
importantly, you have not shown what the compiler would generate in the
presence of extra information. Half the time I am reading your proposed
solutions, I get the feeling you're assuming compiler magic. You don't seem
to
have thought through how the compiler would implement this and the
consequences of it. You'll probably need to prototype the implementation if
you want this to get traction.



> Try moving a polymorphic object using std::move, and you will see how
> widespread the problem is.

>.Why would I want to do that? There are lots >of things that don't work
well,
>but no one cares because no one wants to >use them.

***Answer****
Answer on why I didn't provide a implementation prototype yet:
1. I can't prototype my implementation since the resulting code would be
implementation defined, the only thing that isn't is the expression value
type gurrentied semantics and how it would help people by writing overloads
for that new expression value type.
Semantics is always the first step to a prototyped implementation. A
predator can't catch it's prey if it hasent even seen one. Seeing one is
the core semantics, while catching it is the possible implementations.its
like if rvalues were to be implemented, what would come first? Semantics of
course.

Rest of the answers:
1.I showed my own code to show the issue with verbosity of switch case
statements
2. Then, I went ahead and tried to debunk why virtual functions don't allow
templates to be used, can't be moved, and are too rigid and incomplete for
this task.
3. People do care about move semantics because they are what makes RAII so
efficient and fun to use.
4. Relying on gurrentied semantics isn't compiler magic, it's the
fundamental building blocks of any language.
5. Then, I argued that std::visit is a fancy construct for switch that
fails at removing code that in your words " does nothing ", which is
failure that matters because we do right code that does nothing, in fact in
my virtual machine, instead two switch cases, one for runtime switching and
the other for compile time, I wrote one, and to implement the compile time
one, I simply made it a template that took a integer index and gives it to
the other function. This technique worked and assembly was shortened by a
lot.





>And finally:


> I couldnt sleep because when I close my eyes, tears come which makes pain
> just heat up, so I spent a few hours thinking and combining an answer to
> all your welcomed questions and feedback in one email:
>If this discussion is affecting your health, please take a step back and
relax.
This thing you're proposing, which no one quite yet seems to understand, is
likely going to take years to be accepted, if it is accepted at all. This
is a
marathon, not a sprint.

***Answer****
Thank you for caring, I really appreciate it, but it's not related to this,
it's just that I have a history with skin infections on my thighs and now
it's on my eye.

> 1.Std::move does not work with std::variant unless the destination is a
> std::variant itself, so basically you are locked with std variant for that
> regard.

>Wrong. You can move an object out of the variant through move semantics and
std::get().
****Answer****
I know you are smart (Intel goated) but the issue with std::get is that you
have to use constexpr if statements to make sure the type is right inside
std::visit but even then you can't assign it outside std::visit to anything
other std::variant unless you use checks on the time, which would mean that
the destination type would have to again be a std::variant because in each
block you can't declare the destination to have a different type unless a
union or std::variant.


Thank you for your feedback ❤️❤️❤️❤️❤️❤️


On Sun, 5 Apr 2026, 7:51 am Thiago Macieira via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Saturday, 4 April 2026 18:25:31 Pacific Daylight Time Muneem via Std-
> Proposals wrote:
> > 1.Std::move does not work with std::variant unless the destination is a
> > std::variant itself, so basically you are locked with std variant for
> that
> > regard.
>
> Wrong. You can move an object out of the variant through move semantics
> and
> std::get().
>
> --
> 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
>