Re: [boost] [hana]Either generalization & missing variant

Subject: Re: [boost] [hana]Either generalization & missing variant
From: Michael Caisse (mcaisse-lists_at_[hidden])
Date: 2015-06-08 15:19:36

On 06/08/2015 11:07 AM, Louis Dionne wrote:
>
> 2. I have focused strictly on implementing "compile-time" data structures for
>     now, since that was a sufficiently large task. So I have not taken the time
>     to think deeply about including runtime data structures like a rutime
>     variant, and the effect that would have on the library. I think it is
>     an interesting path to explore. However, I think it might be better to
>     rely on an existing variant implementation and provide adapters for it
>     rather than try to reinvent the wheel (plus I've heard implementing variant
>     cleverly was rather challenging).
>
> So the bottom line is: Hana does not officially provide a sum type
> (variant/Either) for now, and it is not useful as far as my experience
> shows. However, I will take some more time to think about it and come
> up with a good reason to exclude it or a better/generalized interface
> for it, but after the review. See it as a potential feature of a future
> version of the library.
>

Adapters to existing variants makes sense to me. It is the approach 
already used: 
<http://www.boost.org/doc/libs/1_58_0/doc/html/boost/make_variant_over.html>

Converting a type list to a variant is a common thing I need to do. 
Creating yet-one-more-variant type is probably not in Hana's best 
interest. Variant is a priority for C++17 and there are already a 
variety of other implementations.

If you provide an adapter for boost::variant (possibly as a util so it 
isn't a dependency of the core library) then that may satisfy the 
concerns. Optionally, getting an MPL style typelist from Hana would also 
solve these types of interfacing issues.

michael

-- 
Michael Caisse
ciere consulting
ciere.com