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.

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

> On Friday, 3 April 2026 12:00:34 Pacific Daylight Time Muneem via
> Std-Proposals
> wrote:
> > 1.I have discussed it before that std::visit is inefficient/hard to
> > optimize and dosent convey intent and context.
>
> And I've proven that it was very easily optimised, refuting your argument.
>
> --
> 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
>