Re: [boost] A more convenient Variant visitation syntax

Subject: Re: [boost] A more convenient Variant visitation syntax
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2012-04-14 12:39:32

On Sat, Apr 14, 2012 at 5:41 PM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> On 14/04/12 17:00, Kevin Wu Won wrote:
>>
>> While Boost Variant is a wonderful library that fills a genuine hole
>> in the C++ language, it is not as nice to use as it could be. Â The
>> "correct" way to unwrap a variant is to apply a static visitor, but
>> this method carries a high syntactic burden because it needs the user
>> to define a class (probably somewhere far away) just so they can
>> "switch" on the type of the object stored in the variant.
>>
>> I came up with a solution where the handler functions can be specified
>> inline with C++11 lambdas. Â Here's an example:
>>
>> Â  Â  boost::variant< Â int, std::string> Â u("hello world");
>> Â  Â  int result = match(u,
>> Â  Â  Â  Â  [](int i) Â  Â  Â  Â  Â  Â  Â  Â  Â  -> Â int { return i; },
>> Â  Â  Â  Â  [](const std::string& Â str) -> Â int { return str.length(); });
>>
>>
>> The `match` function accepts the variant followed by the handler
>> functions. Â The functions can be specified in any order. Â It will fail
>> to compile if the functions do not match the types of the variant, if
>> the return types are not all the same, or if a non-unary function is
>> supplied.
>>
>> This is C++11 only because it's quite pointless without lambda
>> functions. Â I've tested it with gcc 4.7. Â It doesn't work on gcc 4.6,
>> which can't handle the variadic templates.
>
>
> It can be done in C++03 and expression-template-based lambdas just fine as
> well.
>
> All you need to do is generate a function object that inherits recursively
> from a set of other function objects.
>
> The function objects in question need to be either monomorphic or to be
> sufficiently constrained with SFINAE so that each operator() overload is not
> ambiguous.
>
> Unfortunately, Boost.Phoenix was never extended to support this.

I really like the idea, and i think the C++11-based solution above is
nice! I didn't have the time yet to glance through the code though ...

Phoenix didn't tackle that yet because it is a hard problem ... the
main problem is the syntax how to express which lambda is responsible
for what types. The above solution with C++11 lambdas is nice indeed!
However, what's missing is something like a "catch all" aka a
templated lambda ...
FWIW, independent of this thread I wanted to tackle that for the next
release ...  I'd like to see some propositions on how such a type
based matching could be done with phoenix, which might come down to
have something like pattern matching in functional languages ... I
have no idea how to to do that yet ....