Date: Mon, 25 May 2026 10:12:10 -0700
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.
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.
Received on 2026-05-25 17:12:23
