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