Re: [boost] Variant and visitation (was: [optional] Safe optional)

Le 19/11/14 00:06, Matt Calabrese a écrit :

On Tue, Nov 18, 2014 at 2:52 PM, Sebastian Redl < sebastian.redl@getdesigned.at> wrote:

...

On 18 Nov 2014, at 22:59, Antony Polukhin wrote:

...

2014-11-19 0:40 GMT+03:00 Nevin Liber :

...

It's the inversion of control that people just don't like.

As a guy, who's been keeping an eye on Boost.Variant for last two years, I was planning to add support for generalized lambdas as a visitors for variant:

apply_visitor( [](auto v){ std::cout << v; }, variant_variable ); Alternatively, it could be done like this:

apply_visitor(variant_variable, [](int i) { std::cout << “int: “ << i; }, [](float f) { std::cout << “float: “ << f; }, otherwise([](auto v) { std::cout << “something: “ << v; });

I’ve recently written something very similar for boost::any, using runtime checks instead of course.

The problem with that is it doesn't generalize easily to n-ary visitation.

I have a separate variant and visitation implementation that I've been planning to propose for standardization, but I don't know if it will happen especially since others are on their way. My approach is:

// Called dispatch because of negative connotations of visitor dispatch( overloads( []( int,some_type, float ) {}, []( auto, auto, auto {} ), a_variant, pass_through( not_a_variant ), another_variant ); I'm wondering what should be the result of this function, a variant? or should all the overloads return the same type? This function is close to Haskell fmap/bind.

If variant can contain a non-a-value, we need to determine what is the result when there is not a value for some of the parameters and so the result should be a variant. I know that boost::variant contains always a value, but we can have the none_t as one of them.

All "overloads" does is form an overload set via base-class chaining and bringing in operator() with "using" (appropriately wraps function pointers so they work as well). Return types are deduced by a slightly modified common_type mechanism.

I should be read the post completely. I like the common_type approach. An alternative is to return a variant of the results.You could always convert a variant to the common_type it it exists. Vicente