I think a language facility we have to let the target function decide, whether to evaluate an expression, are lambdas (and any other forms of callbacks), and those should be mentioned in the discussion here.

They can be fully optimized by the compiler as any other construct and are (unoptimized) compatible with different translation units. Even the unoptimized version just has more size, but doesn't do the call, if logging is turned off at runtime. If it is turned on, just the inlining is missing from optimization (without lambdas, the caller would/could inline the evaluation).

The mentioned P0927R2 proposal paper about lazy evaluation was last updated in 2019.

-----Ursprüngliche Nachricht-----
Von: Rainer Deyke via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Mi 28.10.2026 10:37
Betreff: Re: [std-proposals] Modularized logging library - prevent parameter evaluation before calling
An: std-proposals@lists.isocpp.org;
CC: Rainer Deyke <rainerd@eldwood.com>;
On 10/28/26 10:00, Alexander Christensen via Std-Proposals wrote:
> Hi,
>
> Someone reminded me of my erroneous logging function:
> LogWarn("Invalid Value {}", GetValue());
>
> The function is defined like this:
> template<typename... Ts>
> void LogWarn(std::string_view fmt, Ts&&... args)
> {
> #if defined(LOG_WARN)
>      // log...
> #endif
> }

You can do this by making LogWarn a macro.  You *should* do this by
making LogWarn a macro.

One guarantee in C++ is that given functions f and g in the code f(g()),
function f cannot prevent g from being called or affect the evaluation
of g() in any way.  It's a tradeoff that makes code easier to understand
at the cost of limiting the expressive power of the language.  And there
already is an escape hatch: turn f into a macro, and the guarantee goes
away.

You are proposing a second escape hatch, presumably because you don't
like macros.  I don't think that's a good enough reason.

In some other languages, given the equivalent of f(g()), the function f
can control when and if g() is evaluated.  And that's fine for those
languages.  It comes at a significant cost in conceptual complexity, but
it allows these languages to simplify in other ways (such as by turning
flow control structures into regular functions).  But C++ doesn't have
to, and shouldn't, imitate them.


--
Rainer Deyke - rainerd@eldwood.com
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals