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

Subject: Re: [boost] Variant and visitation (was: [optional] Safe optional)
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2014-11-18 19:06:26

On Tue, Nov 18, 2014 at 3:39 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> // 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.
>

It depends on the situation. I return a common_type-like deduction that's
reference-aware, but some cases you want it to return a discriminated
union, and other cases you want it to just be a user specified result. It's
very usage-dependent.

> 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.

IMO boost is correct with the never empty guarantee and a standard version
would be wise to follow suit. If you put in a type that you happen to treat
as a null type for your specific case, then that's fine. It's nothing
special in that sense apart from how personally interpret it. Visitation
simply passes it along as one would expect.

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.

The only problem with a default variant-as-result approach is that in
practice I've personally found that it's not as frequently useful (I know
someone else on this list who has use-cases for the variant return though
-- perhaps he'll respond). As well, if you get back a variant/discriminated
union of the result types, collapsing that result in a separate step
effectively requires another visitation.

Ultimately the user should specify the kind of deduction they want or
provide an explicit result type at the time they perform the visitation. I
just find common_type to be most common for my personal needs.

-- 
-Matt Calabrese