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.