On Fri, Nov 29, 2013 at 11:47 PM, Sumant Tambe
Well, gcc 4.9 has a name lookup bug ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58820) and Visual Studio 2013 Nov CTP chokes on lambda multiple inheritance.
Also, I'm not sure what you are suggesting with the struct F example. Simply bringing the base class's operator () in the current scope does not provide "typeswitch" capability.
In other words, you pull in the operator () from each of the function objects and then just invoke the composite object's set of overloaded operator() functions. You get exactly the behavior of overload resolution of a qualified name because that's exactly what's going on. It also should not be at all slower than simply invoking a function. This will work fine for things like variant visitors right out of the box, too, assuming you inherit from boost::static_visitor. If you want to support type-erased objects, it's not quite that simple, though I personally am not very interested in those capabilities. At the very least, it should be possible to make the simple, overload-based one without the overhead of a more dynamic approach. The only issue I immediately see with the overload implementation is that it will require special handling if someone passes in a function pointer, which is a perfectly valid function object so you'd expect it to just work as a user of match. That said, support for function pointers would still be very easy to add in, it's just something that shouldn't be forgotten. Anyway, regardless of the implementation, I do think that this is a worthwhile tool. Make it inherit from boost::static_visitor and I'll start using as soon as I can. It should be possible to automatically deduce the return type in some cases, especially with the help of a type list of possible arguments (a variant type or instance would also be an option), falling back on an optional, user-specified return type via an explicit template argument. This would be extremely useful for creating boost::variant visitors right at the apply_visitor call-site. It might even make sense to have something like this that does the visitation right when the object is formed, given that simply using it once as an argument to apply_visitor seems like a common use-case. -- -Matt Calabrese