I honestly do not really like the idea that the logging facility can change
how the program behaves. In the best of all worlds, the compiler _should
already be able to discern_ that the result from g() is discarded if the
logging is disabled, and if g() is pure, the compiler should be allowed to
move the function to inside the conditional under the as-if rule.

It does not work, however, if either the logging function or g() is hidden
in a separate TU. The latter could be solved if we allowed a
[[pure]]-attribute, but it is of my understanding that the attribute came
with more risk than reward as well as some difficulties to define what
exactly is 'pure'.

Just my opinions anyway.
// Robin

On Wed, Oct 28, 2026, 10:40 Alexander Christensen via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi, and thank you for responding!
>
> To your question, Rhidian, my idea was to remove the function call at
> compile-time and throw an error if the function is non-void or not ignored
> with std::ignore.
> But the idea of decorating the function with something like "[[ ... ]]"
> could be used for a multitude of purpose, and cannot be a template-syntax
> or a reflection. Call it a "Decorator"?
> And that sounds like a pretty big thing that would/should cover a lot more
> than simply removing a function call.
>
> Your case of runtime-decision making, Pavel, is something I had not
> thought of. It sounds really cool, but I was only thinking about
> compile-time.
>
> Tiago:
> I can't think out of my head what other uses there would be. Probably
> someone out there needs something like this for *something*, but that
> sounds like a big if.
> So probably not worth the trouble, no.
>
> Just read Rainer Deyke's no. email, which pretty much settles it with a
> convincing argument, as I was writing this.
>
> Thank you for entertaining this idea.
> Best,
> Alexander
>
> ------------------------------
> *Fra:* Pavel Vazharov <freakpv_at_[hidden]>
> *Sendt:* 28. oktober 2026 10:10
> *Til:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Cc:* Alexander Christensen <alex_c007_at_[hidden]>
> *Emne:* Re: [std-proposals] Modularized logging library - prevent
> parameter evaluation before calling
>
> Hi,
>
>
> In my ideal world, I could define my logging function like this:
> [[ConditionalDiscard = IsShipping()]]
> template<typename... Ts>
> void LogWarn(std::string_view fmt, Ts&&... args) { /* ... */ }
>
> I assume the function IsShipping() to be constexpr.
> And the effect would be a function call completely stripped
>
> What about the other cases where the decision for logging based on the log
> level is taken at runtime?
> For example, I've worked with systems where the logging level for a given
> sub-system of the application (or the whole application) can be changed at
> runtime and this helps collect more information about specific production
> issues.
> However, we still wanted lazy evaluation of the parameters because these
> logs are still disabled 99% of the time.
> We used macros for our logging systems. At least I don't know a better
> alternative for this.
>
> Regards,
> Pavel.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>