Re: [boost] [variant] Maintainer

Subject: Re: [boost] [variant] Maintainer
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2015-06-28 10:29:04

On 6/28/2015 5:38 AM, Vicente J. Botet Escriba wrote:
> Le 27/06/15 21:32, Agustín K-ballo Bergé a écrit :
>> On 6/27/2015 12:38 PM, Vicente J. Botet Escriba wrote:
>>> I would accept Eggs.Variant without even a review (or with a minimal
>>> review) as an experimental library as part of Boost.Variant after some
>>> minimal adaptation to fit in Boost of course.
>> First of, as I have already said before, Eggs.Variant is an
>> experiment. As such it is highly unstable, and I reserve the right to
>> change things in any way I see fit, with no regards for backwards
>> compatibility, maintenance, or support. I have made these kinds of
>> changes in the past, and I have more planned for the near future. I
>> think it would be unwise to make it a part of Boost, even as an
>> experimental library, until the design has fully hatched ("Eggs", get
>> it?).
> Agustin, this is exactly the kind of constraints of an experimental
> library. When the design is fully hatched then it moves to non
> experimental.

I fail to see the point in including an experimental library that 
changes its interface every month into Boost, which is released every 3 
months or so. By the time you get your hands in a release, the interface 
of the library has already changed. And the library as such would only 
exist for a single release.

Who would benefit from Boost packaging old snapshots of experimental 
libraries?

Perhaps you'd wish to bring back the Sandbox 
(http://www.boost.org/community/sandbox.html), which has been superseded 
by standalone repositories since the move to Git.

>> For instance, the visible empty state is not going anywhere. As a
>> fundamental building block, I cannot afford to pay the cost of double
>> buffering, heap allocation, restrictions to nothrow-move-constructible
>> alternative types, etc.
> There is something that I don't like of the possibly empty variant. It
> confounds the empty state and a hidden error state. When we assign a
> type A to  variant containing a type B the resulting variant can be
> empty (contains a different type C).

Eggs.Variants doesn't have an error state, only an empty state as 
`union`s do. Switching the active member of a `union` is a two step 
operation:

- First the active member (if any) is destroyed, leaving the `union` in 
an empty state (no active member).

- Then, a new member is activated via in-place construction. If 
construction fails with an exception, the `union` remains empty.

>> The abstractions I built on top of it might, since they are the ones
>> who attach meaning to the variant, but it is up to them to make those
>> choices. Likewise, I'm not considering implementing support for void
>> and reference types as alternatives.
> Could you tell us more about the rationale? it is because some wrappers
> as void_t and reference_wrapper<T> can be used instead?

It is because `union`s don't take those as members.

I did briefly experimented with implicit conversion to wrappers, as 
those you mention, but it interacted in funny ways with interfaces where 
a "scalar" value appears (construction, assignment, relational ops). I 
concluded that forcing the higher level abstraction to do the wrapping 
and be aware of it would be less surprising.

> BTW, how eggs::variant<T,T> behaves?

Just as a `union U { T a; T b; };` would. It has two distinct members, 
and you can only access the active one.

Eggs.Variants additionally provides access to the underlying storage, 
both raw and typed, via its `target` member function. Based on recent 
discussion on the reflectors, I will be modifying `target<T>()` to be 
able to access it when either of the two members are active, since it's 
logically equivalent to a cast on the underlying storage address and I 
understand it to be well-defined under strict aliasing rules (see 
http://melpon.org/wandbox/permlink/Zw59kxEmvp7M82M5).

There are several other places in which I have yet to consider whether 
SFINAE or hard error is appropriate.

As far as I know, I only depart from what a `union` would do for 
initialization. Due to the discriminator, I cannot provide both 
default-initialization and value-initialization as `union`s do, so I 
only provide the cheap one.

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