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 19:21:07

On 1/6/2016 8:58 PM, Robert Ramey wrote:
> On 1/6/16 3:09 PM, Glen Fernandes wrote:
>> Robert wrote:
>>> c) Is there any reason that you haven't submitted this to the Boost
>>> Library Incubator?
>>
>> Agustin's reasons in this thread:
>> http://lists.boost.org/Archives/boost/2015/06/223920.php
>>
>> Glen
>
> Wow - I think I saw some of the thread but it didn't register with me.
> This is probably because I wasn't interested in variant at the time. Two
> things stand out for.
>
> a) The proposal to bring back the sandbox - To me that's what the
> incubator is.

+1 That's exactly my position.

> b) I cloned it, built it and ran the tests.  After a very minor hassle
> with CMake, Everything worked great.

I'd be interested in know what you did with CMake. Feel free to contact 
me off-list with the details.

> c) So this is definitely something that can/should be in the incubator
> right now so people can easily find it and experiment with it.  The
> requirements of the incubator are designed to:
>
> 1) submit code that actually works so it's worth trying
> 2) provide the author with useful feedback bug reports, etc.
>
> So, to me, this is an absolutely ideal candidate to be in there.

What about stability? That's my main concern; the other one is what 
would this cost me? Do I have to adopt boost directory layout, move to 
boostbook documentation, etc? I have no intention of putting any effort 
towards that **at this point in the library's lifetime**.

> As a side note, the documentation isn't particularly easy find.  The
> github project has the mark down but not the html so one has to google
> around for it.  Also there are two articles which have very useful
> information - but they aren't easy to find either.

The link to the documentation is on the first line of the README. 
Generated HTML is kept out of band, as to prevent it from cluttering the 
commit history.

Where were you looking for it? Maybe in the "docs" directory? The README 
on that directory also links to the documentation. I'm not sure what I 
could do to improve on that, your input is welcomed.

I could add links to the articles too, although the documentation 
already paraphrases the first one, and the second is just on distracting 
(and infuriating) implementation details.

> And one more thing.  I added the library into my project - and damn! it
> seems that eggs::variant::variant<int, std::overflow_error> isn't a
> literal type!!! that is std::is_literal<variant<int,
> std::overflow_error> returns false_type.  This is the original
> motivation for looking beyond Boost.Variant.  It's essential for me to
> be able to replace my home brew variant which I want to do.  I need this
> to be part of a constexpr function.

Well of course, since `std::is_literal<std::overflow_error>` yields 
`std::false_type`. However, I doubt that you actually want to store an 
entire exception within the object, perhaps an `std::error_code`?

The `expected` proposal might be better suited for this purpose.

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