Or you can just call a spade a spade, if you want to delegate the call of a function delegate the call of a function.
Doing this is already a thing that you can do with the language, stop with the hacky nonsense. Stop trying to hijack language features to do other things that they weren't designed to do.
All you need is an extra interface to explicitly call a function, which is what you want to do. The simplest solution is often the right one.



________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
Sent: Friday, May 31, 2024 12:33:52 PM
To: std-proposals <std-proposals_at_[hidden]>
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Subject: Re: [std-proposals] std::elide

On Fri, May 31, 2024 at 10:10 AM Matthew Taylor wrote:
>
> > Did anyone like my previous idea of having a way of
> > telling the compiler that we want template instantiation to fail?
>
> At the risk of stating the obvious, the difficulty there is that such
> an idea is a sledgehammer which could be a major change to
> template programming; and such an idea needs serious, strong
> motivation which goes far beyond being a workaround to make
> a different proposed feature's edge cases work. Particularly as
> at least a few of the potential use-cases for it can already be
> achieved in the language as it is now.


Well . . . while we're sharing revolutionary ideas for the upheaval of
the language . . . (Bjarne did it so I can too) . . .

Let's look at what the real problem is here. The following fails to compile:

    optional<mutex> om;
    om.emplace( FuncReturnsMutexByValue(1,2,some_global_variable) );

It fails to compile because "FuncReturnsMutexByValue()" is a PRvalue,
and the 'emplace' method won't accept a PRvalue. But let's say that
the C++ programming language were to be augmented in C++26 to allow us
to write a function that accepts a PRvalue as an argument as follows:

    template<typename T>
    T &emplace(T ^^arg);

which for our above variable whose type is "std::optional<mutex>" becomes:

    mutex &emplace(mutex ^^arg);

So now when the compiler encounters the following line:

    om.emplace( FuncReturnsMutexByValue(1,2,some_global_variable) );

It does the following:
    Step 1 - Determine that the argument to 'emplace' is a PRvalue mutex
    Step 2 - Check whether "optional<mutex>::emplace" has an overload
that takes a PRvalue mutex
    Step 3 - Immediately evaluate the arguments which are passed to
"FuncReturnsMutexByValue", however delay the invocation of
"FuncReturnsMutexByValue" until the 'emplace' method explicitly
invokes it.

And so then the implementation of
"std::optional<mutex>::emplace(mutex^^)" would be as follows:

    mutex &emplace(mutex ^^arg)
    {
        this->reset();
        T &retval = ::new(this->buffer) mutex( arg() );
        this->has_value_bool = true;
        return retval;
    }

And so as you can see in the above snippet, the argument 'arg' is a
functor object which invokes "FuncReturnsMutexByValue" with the
arguments "1, 2, some_global_variable". As I mentioned earlier, the
evaluation of the arguments "1, 2, global_variable" happens before the
'emplace' method is invoked.

So there you have it people -- C++26 needs to have functions that
accept PRvalues as parameter types.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]g
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals