С++ variadic templates: implement variadic functor - c++

Question

My colleague provided me with a "small quiz", that he made his students solve once. It seems that my feeble mind is just unable to comprehend all the beauty of the modern C++ capabilities.
Subj:
Implementing a join function, accepting arbitrary functors and returning another functor, which behaves as any of them. Ex.:
{
auto result = std::visit(custom::join(
[](std::string const& s) { return "it's a string"; },
[](std::pair<int, int> const& p) { return "it's a pair"; }
), var);
assert(result == "it's a string");
var = std::make_pair(10, 20);
auto lvalue_lambda = [](std::string const& s) { return "it's a string"; };
result = std::visit(custom::join(
lvalue_lambda,
[](std::pair<int, int> const& p) { return "it's a pair"; }
), var);
assert(result == "it's a pair");
}
Okay, after a bit of thinking I got the idea, that std::variant means "one of the listed" as far as it is a "type-safe union", so I'll need a tuple. Tried something like that:
namespace custom
{
template<typename ...Functors>
class ResultFunctor
{
public:
ResultFunctor(Functors&&... funcs)
: m_funcs(std::make_tuple(std::move(funcs)...))
{}
template<typename ...Params>
auto operator()(Params... params) // that's where I got stuck
{
// return std::get<void(Params...)>(m_funcs)(params...); // No, the return type spoils this idea
return std::get<0>(m_funcs)(params...); // Now I need to choose the correct functor
}
private:
std::tuple<Functors...> m_funcs;
};
template<typename ...Functors>
ResultFunctor<Functors...> join(Functors&&... funcs)
{
return ResultFunctor(std::move(funcs)...);
}
}
If it were only for functors with void return type, I'd easily get the desired element of tuple. But there seems to be no way to determine it, return type cannot be deduced from given parameters (obviously).
Another idea was to use some SFINAE trick to choose the correct operator()() version, but this way or another I'll have to "run through" all the tuple item (which is nasty, but still can be googled) and then check if that item is suitable, based on the given parameters pack.
Well, that's where I took a pause to think it over thoroughly. If anyone (who deals better with all that variadic stuff) would have any ideas, I'd be really grateful.

Answer 1

This has a really simple solution that doesn't involve SFINAE or template metaprogramming (just regular templates).
The first step is to write a functor which represents the joint overload set. This is easy to achieve with inheritance, and because all the functors used as inputs must have different types, we don't have to do anything fancy.
// This represents overload set
template<class F1, class F2>
struct Joint : public F1, public F2 {
using F1::operator();
using F2::operator();
};
For user convenience, we can add a deduction guide:
template<class F1, class F2>
Joint(F1, F2) -> Joint<F1, F2>;
Because Joint is an aggregate type in C++17 and above, we don't have to provide a constructor because we can use aggregate initialization:
// This code magically works
auto result = std::visit(Joint{
[](std::string const& s) { return "it's a string"; },
[](std::pair<int, int> const& p) { return "it's a pair"; }
}, var);
Writing a custom::join function is equally simple:
template<class F1, class F2>
auto join(F1&& f1, F2&& f2) {
return Joint { std::forward<F1>(f1), std::forward<F2>(f2) };
}
Now that we have the base case, we can generalize it pretty easily:
template<class F, class F2, class... Fs>
auto join(F&& f, F2&& f2, Fs&&... fs) {
return Joint{
std::forward<F>(f),
join(std::forward<F2>(f2), std::forward<Fs>(fs)...)
};
}
Addressing potential criticisms
Why not define a constructor for Joint? Aggregate initialization is the most efficient form of initialization, because when you don't define a constructor the compiler is capable of assigning values in-place without having to copy or move them.
Why use multiple inheritance? If we rely on SFINAE, that increases compiletimes, increases code complexity, and it doesn't work as expected in some cases. With SFINAE, you have to check each member of the overload set to see if it's a fit. In some cases, due to implicit conversion, a worse overload is chosen because it was a match.
By using inheritance, we can use the languages' built-in pattern-matching for function calls.
Why add deduction guides? They make the code cleaner, and in this case they work exactly as expected: arguments are stored by value

Answer 2

namespace custom {
template<class...Fs>
struct overloaded : Fs... {
using Fs::operator()...;
};
template<class...Fs>
overloaded(Fs...)->overloaded<Fs...>;
template<class F>
F&& as_obj( F&& f ){ return std::forward<F>(f); }
template<class R, class...Args>
auto as_obj( R(*f)(Args...) {
struct helper {
R(*f)(Args...);
R operator()(Args...args) const { return f(std::forward<Args>(args)...); }
};
return helper{f};
}
template<class...Fs>
auto join( Fs&&...fs ){
return overloaded{as_obj(std::forward<Fs>(fs))...};
}
}
I added as a bonus support for non-overloaded function pointers.