Directions of the proposal(s) could go into the following directions:

Delayed execution similar to or based on lambdas:

-> Simpler/shorter syntax for some lambda usages

-> standardizing the type of a callable, which returns a certain type T, so that it can be used as non-template-parameter; we already have several std::function and similar constructs

-> a lambda or std::lazy, which optionally (two types or how evaluation is called) caches its value returned at the first evaluation for the second use (and beyond)

Coroutines:

-> P2506 std::lazy<> for coroutines

Compile-time replacement:

-> a program snippet or AST-near way to call code. Replacement  for C macros, see code generation/metaprogramming/reflection

-> quoting a C++ expression or program snippet and making it a compile-time object, which can be evaluated/called or analyzed (token list vs. typed expression?)

-----Ursprüngliche Nachricht-----
Von: Thiago Macieira via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Mo 25.05.2026 19:12
Betreff: Re: [std-proposals] Perfect forwarding for prvalues / expression templates
Anlage: signature.asc
An: std-proposals@lists.isocpp.org;
CC: Thiago Macieira <thiago@macieira.org>;
On Sunday, 24 May 2026 22:12:48 Pacific Daylight Time Mital Ashok via Std-
Proposals wrote:
>     std::lazy<int> x = f(); // f is not called here

f() MUST be called here because of syntax. If you want to change the core
language evaluation rules, then this must be a core language change.

Unless you meant f without the ().

I understand the intent, because it would allow

   std::lazy<int> x = f(1);

whereas a non-call syntax would require std::bind or a lambda. But let's take
this further:

   std::lazy<int> x = f(g(y));
   y = 0;

Is g() called now, or lazily? When x is finally evaluated, will it see the
consequences of y = 0 ?

>From another reply:
> The whole point is that it would be as frictionless as possible at the
> call site. The exact same issue appears currently with
> assert/debug/log macros, where we expect the macro writer to have
> sensible semantics about whether/how many times a macro argument is
> actually evaluated.

Frictionless does not mean invisible. Macros that may evaluate an expression
zero or more than once are a source of trouble. Sometimes that's intentional
and therefore clear to the user of the macro that it shall be the case, but in
a general sense where macros appear to be regular functions, that is a
surprise factor.

It might be preferable to have an explicit marker in the caller instead of
marking the callee. That would open up to more uses where currently functions
don't expect lazy arguments... it might be the terse lambda proposal.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
 Principal Engineer - Intel Data Center - Platform & Sys. Eng.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals