Re: [boost] [variant] Maintainer

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

On 6/29/2015 3:58 AM, Vicente J. Botet Escriba wrote:
> Le 28/06/15 16:29, Agustín K-ballo Bergé a écrit :
>> 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.
> Yes, Boost.Experimental could be something like the old sandbox, but
> instead of having a sandbox that is not fixed, it will be fixed 3 times
> a year. This gives some stability to users that want to play with.

I don't see the point in this. Stabilizing an experimental library 
interferes with experimentation. And once an experimental library is 
stable enough to leave the new distributed sandbox, the ideal place for 
it would be the blincubator.

I think I have made this point several times already. My position should 
be clear by now, so I'll just shut up about it now.

>>> 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).
>>
> While I see added value to variant <T,T> I would make any access with
> the type T ill-formed, as you do already for get, and provide access
> only throw the index. `union U { T a; T b; };` works because we have
> using tags `a` and `b`, but i doest provides access by type.

I'm not sure what your feedback is here. Access via `get<T>` is already 
ill-formed when `T` is not unique.

>> 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.
>>
> Why you can not default initialize to index 0?

What I meant is that, unlike unions, I cannot give different meaning to 
these two:

    U u; // no active members
    U u{}; // first member active

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