Re: [Boost-users] boost variant is not a literal type

Subject: Re: [Boost-users] boost variant is not a literal type
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2016-01-06 18:58:04

On 1/6/2016 7:23 PM, Robert Ramey wrote:
> On 1/6/16 1:03 PM, Agustín K-ballo Bergé wrote:
>> On 1/6/2016 5:52 PM, Robert Ramey wrote:
>>> I want to use Boost.Variant constexpr function. In order to do this it
>>> has to be a literal type - which apparently it isn't.

>>> Has anyone else had this problem before and managed to solve it in a
>>> convenient way?
>>
>> Constexpr support is a complicated thing for `variant`, and it would
>> require a complete reimplementation of `boost::variant`. The trickiest
>> part is having a trivial destructor.
>
> I've read your eggs.variant and it seems exactly what I'm looking for so
> I cloned.  I used CMake to make and xcode project and I've got a couple
> of questions:
>
> a) It doesn't seem to specify CTest, at least my xcode project doesn't
> have a "RUN_TESTS" target.  I try to build the tests and I get error
> messages like:
>
> /Users/robertramey/WorkingProjects/variant/include/eggs/variant/detail/pack.hpp:22:9:
> Unknown type name 'constexpr'
>
> at line which contains "EGGS_CXX11_CONSTESPR"
>
> which suggests that I haven't got things setup quite right.
>
> a) Am I correct in my understanding that this will provide similar
> facilities to boost variant in way which supports constexpr?

No, the fundamental model of Eggs.Variant is that of a discriminated 
union while Boost.Variant models a type sum. Those are terms that I made 
up and that I describe here: 
http://talesofcpp.fusionfenix.com/post-21/rant-on-the-stdexperimentalvariant-to-come

> b) Anything I haven't done to run test on and use this library.

I use CMake to run the unit tests and it Just Works. Perhaps a missing 
-std=c++11 (or greater) flag?

> c) Is there any reason that you haven't submitted this to the Boost
> Library Incubator?

The library is meant for experimentation only. I will break backwards 
compatibility or stop supporting compilers I no longer need as I see fit 
(msvc needs quite a lot of cruft and it still only gets a fraction of 
the features). Once the library stabilizes I would consider submitting 
it to the blincubator. Recent experimentation with concepts led me to 
believe they will be a game changer for the implementation, and that 
they will make a perfectly transparent discriminated union tractable, so 
that might be a while.

Furthermore, I believe Boost would benefit more from a library tracking 
the `variant` proposed for standardization (now that we finally have 
design agreement), and Eggs.Variant is deliberately not that.

Regards,
-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com