How store polymorphic closures?

Question

C++1y offers polymorphic lambdas (i.e., using auto as part of the parameter type):

int         f(int);
double      f(double);
std::string f(const std::string&);

auto funcObj = [](const auto& param){ return f(param); }

Storing the closure generated by the lambda is easy, as shown: just use an auto variable. But suppose I'd like to create a vector of such objects. What type does the vector hold? The usual answer is to use std::function, but that doesn't work in this case, because there is, AFAIK, no such thing as a polymorphic std::function, i.e., this isn't legal in C++1y:

std::vector<std::function<auto(const auto&)>> vecOfPolymorphicClosures;

If this were legal, then you could do things like create a container of callbacks, each of which could be called with any set of arguments and each of which could return a type that's dependent on the types of the arguments passed. The result of any given callback could be stored in an auto variable, at least in theory.

Two questions:

• Is there a way in C++1y to declare a variable or container that can hold different types of polymorphic lambdas (other than something like boost::any)?
• Is it even reasonable to hope that such a thing can be possible, or would this kind of thing be incompatible with static typing?

Answer 1

No. Well maybe.

For your particular case, your lambda is just an override set of a single function f known at instantiation. Override set objects can be created and passed around with type erasure without much of a problem. You just need to manually enumerate the overrides and provide it to the override set.

So if your goal is to just have an object that is the override set of f, yes, you can do this. See "Manual" signature overload resolution -- add in some type erasure on top of that mess, and bob is your uncle.

The general case, where you have some auto lambda with arbitrary code within it, no.

The way to envision this problem is imagine a DLL or shared library compiled with your lambda, a second DLL or shared library holding the function like object, and some other DLL or shared library wanting to call it.

The behavior of what happens when you call the function is dependent on the definition of the lambda and the type that you want to call it with to an arbitrary degree.

In order for this to work, a nearly complete run time compilation model would have to be available in both the DLL where the lambda was created, and the DLL where the type it is called with, and that run time compilation model would have to be compatible.

This is both not required by the C++ standard, and would make things far more complex if it was, and would eliminate optimization opportunities.

Now, not all is hopeless.

If there is some fixed list of types you want to support, a polymorphic function signature can be written. This is basically a special case of the 'override set' solution above, and can even be written using it.

On the other hand, if you are willing to type erase the properties of the arguments to your lambda, and type erase, and return some uniform type (be it boost::any or boost::variant or whatever), you can do something. You write up a type erasure object type, and expose it. Then you have a std::function< boost::any(type_erasure_object) >, and the conversion occurs outside the call, and within the call you deal with said type erased object.

Picking overloads using a type erased object is tricky, in that the C++ compiler doesn't help you much with producing a list of overloads to consider. If you collect that list manually, you can even type erase which overload you'll pick.

Pulling that off is possible, but I have not written it before. The alternatives to this are all far easier.

I don't consider the type erased case to solve this problem, as it blocks certain kinds of optimizations. But in theory, it means that you can work with a nearly arbitrary type.

The type erasure object must be exposed to the end user, and it must erase every piece of type information that every lambda you shove into that std::vector needs to know. So this can significantly restrict what lambdas you are storing in your std::vector in some cases.

For an example of how to type erase nearly arbitrary objects, look at boost type erasure.

Finally, what you are asking for is rarely an actual requirement of a problem. You would be best to describe your actual, practical problem, which almost certainly has solutions that are not nearly as esoteric as those above.

Answer 2

The type of a so-called generic lambda is a class-type with a member template operator(). When a conversion is required, the actual type has to be known. For a non-capturing generic lambda, the current draft standard even contains an example:

auto glambda = [](auto a) { return a; };
int (*fp)(int) = glambda;

This is no different from forming a function pointer from an ordinary function template.

For a general generic lambda, I imagine that conversions that expect a callable object will trigger the correct template specialization, so that std::function<int(int)> f(glambda); should work just fine.

Answer 3

What I want to store are objects of different types, but each can be called with a potentially unlimited set of argument types.

Translation unit A:

// a.cpp
#include <cassert>

std::vector<magical_type> v;

struct lives_in_a { int i; };

// defined in TU B:
void prepare();

int main()
{
    prepare();
    assert( v.front()(lives_in_a { 42 }) == 42 );
}

Translation unit B:

// b.cpp

struct lives_in_b {
    template<typename Anything>
    int operator()(Anything const& a) const
    { return a.i; }
};

void prepare()
{
    // ignore global initialization order fiasco for the sake
    // of the argument
    extern std::vector<magical_type> v;
    v.push_back(lives_in_b {});
}

When and where is lives_in_b::operator()<lives_in_a> instantiated, so that it may be called?

When v.front() is called with argument lives_in_a {}? In that case there is no definition of lives_in_b in sight, so little to even instantiate.

When v.push_back(lives_in_b {}) is called? In that case there's no definition of lives_in_a in sight, so there's isn't much the would-be instantiation could do with.

This is a demonstration that the particular combination of the compilation model of C++ and the way template instantiation work, doesn't allow for that particular wish. It has less to do with static typing.