Re: [boost] An open typeswitch using lambdas

Subject: Re: [boost] An open typeswitch using lambdas
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2013-11-30 03:37:00

On Fri, Nov 29, 2013 at 11:47 PM, Sumant Tambe <sutambe_at_[hidden]> wrote:

> 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