I feel like you are missing the ball here by a huge margin. To begin with:
Your main "Removing the function call at compile time thing" isn't a
foreign idea, like it's a part of template metaprogramming already, like we
have requires{} clauses to filter functions based on any criteria.
Secondly, your idea is worse since it requires extra effort by the
implementers to throw an error if it's a non-void function and a value is
expected, whereas with the former, you dont have that disadvantage. Even if
you were to say that using these constructs you can sneak in pre and post
condition checks, then sadly for your proposal, that ship has sailed away
in C++26. What you are left with is reforming the way you write code to
make use of the features at hand rather than trying to propose rather
confusing shortcuts.Type and function Attributes are a terrible fit for
something like this, since their main goal is to aid reflections and your
proposal misses that mark by a huge margin. You could however invent useful
compile time discriminator functions and then propose them, but attributes
are just not the way. The use of "multitude of purpose" (a term I used to
use a lot) sums up what's going through your mind to make you suggest
reinventing the wheel.

Have we really forgotten that you can discriminate between functions using
requires{} classes from 2020?

On Wed, Oct 28, 2026 at 2:40 PM 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
>