Re: [boost] [variant] Maintainer

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:

...

...

...

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

On 6/27/2015 12:38 PM, Vicente J. Botet Escriba wrote: 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

Le 27/06/15 21:32, Agustín K-ballo Bergé a écrit : 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 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 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