Boost logo

Boost :

Subject: Re: [boost] Variant and visitation (was: [optional] Safe optional)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-11-18 18:39:34

Le 19/11/14 00:06, Matt Calabrese a écrit :
> On Tue, Nov 18, 2014 at 2:52 PM, Sebastian Redl <
> sebastian.redl_at_[hidden]> wrote:
>> On 18 Nov 2014, at 22:59, Antony Polukhin <antoshkka_at_[hidden]> wrote:
>>> 2014-11-19 0:40 GMT+03:00 Nevin Liber <nevin_at_[hidden]>:
>>>> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at