My response to Mr.Marciene's welcomed feedback is:
1. The reason that I assumed how compiled work is because according to the
fundamentals of compiler design theory, the phase of optimization also
known as code optimization requires intent and context to be described in
intermediate code generation, so llvms are out of the question since they
are intermediate code, and the goal is to write good intermediate code, and
to rely as less on low level of generation as possible. Why?
Because that's why we don't code in llvm form or language or whatever, and
why we don't prefer these higher level compiler language.
2. Again, my proposal is that the problem exists because we have to address
it at a llvm level, not at a language level. Wouldnt it be concerning if c#
has constexpr functions, but c++ relied on llvms to optimize functions?
That's how I feel when I know that GO has heterogeneous lists but c++ does
not.
3. I didn't assume how compilers work because how llvms work is none of my
business, I am interested in intermediate code generation, that's all I
want. llvms is the domain of expert Intel programmers not a guy trying to
propose features to the c++ language.
4. Developers do care about compile time (my small project takes a lot of
time to compile (only 3000 lines the last that I compiled it), and making
it worse by relying on llvms that probably has a higher volume of code
since lower level is less about defining constraints and more about getting
things done.
5. My main point about templates was that the compiler is smart enough to
assume weather it can do it well, or should leave it to llvms or something
deeper down the line, but templates were just an example not my main point.
6. Relying on compilers to be smart enough on techniques in the standard
library (std::visit) or for your code is never a good idea since it's
mostly compiler backend/intermediate code compiler (llvm stuff) defined,
instead of the standard.
7. It is an unsolvable problem, in that we need to rely on backbends to
spend effort, which we can't really force them too, since they are compiler
backends, and since they can't arbitrarly spend loops upon loops trying to
find every optimization technique that they can apply.
8. I can wait for optimizations, but optimization is at intermediate code
generation level (c++ compiler domain), so there is probably, but to fix
it, we mask it.
9. I added points on code bloat (credit to the email by Mr.Adrain) because
code bloat is real, without help by the compilers intermediate code
generation, the llvm or any other tool can't do much without it having a
chance to backfire.



On Sat, 4 Apr 2026, 4:12 am Thiago Macieira via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Friday, 3 April 2026 15:56:41 Pacific Daylight Time Muneem via
> Std-Proposals
> wrote:
> > Even if it is, it will be optimized for a single expression and the
> > optimization might backfire, and the optimization would imply significant
> > compile time overhead that would grow exponentially if the compiler wants
> > to do it right, and linearly if it's just inlining it blindly on judgment
> > of a single expression bases. The goal isn't to make a construct that
> easy
> > to inline, but rather one that is easy to optimize in every regard and
> for
> > the whole program, and a construct that is also less verbose and implies
> > less space overhead than std::visit can. Std::variant is just a dump
> union,
> > not fit to be heterogeneous list element type.
>
> Any particular optimisation may or may not be applied, given context. See
> the
> other discussion on adding information via [[assume]] has caused LLVM to
> cease
> to apply some optimisations.
>
> You're making assumptions about how compilers work -- or worse, how they
> must
> work -- without supporting evidence. I've asked you before whether this
> was an
> inherent problem that cannot be solved no matter how smart the compiler is
> or
> if we cannot wait for the compiler to become that smart. You answered that
> it
> was the latter case: it's a widespread problem that must be solved now.
> That
> implies you don't think it's an unsolvable problem. So please stop arguing
> about how optimisations may backfire. And besides, most developers don't
> care
> too much about compilation time: only runtime matters.
>
> In any case, as you're arguing that it's a widespread problem that must be
> solved with new techniques and not waiting for compilers to be smart
> enough,
> please provide evidence: link to 10 separate instances in open source code
> where this problem appears, either in current code or in commits working
> around the problem.
>
> --
> 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
>