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.
Vicente, while this is really flattering, I feel compelled to clarify a few things.
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
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.
Second, Eggs.Variant is not tracking the standard proposal, which it predates, nor it looks like it's going to converge with it.
I know that, and this is why I want libraries as yours to be part of Boost[.Experimental].
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. I know that your variant is possibly empty and the C++ standard proposal is never-empty, and this makes them different from the user point of view. Bjarne S. and Anthony W. are pushing towards a possible empty variant, we don't know yet what the std::experimental::variant will be and less yet what std::variant will be in C++17.
boost::variant combined with boost::blanc gives this kind of possibly empty variant, but IMHO this is a quite different type. template <class ...Ts> using optional_variant = boost::variant<boost::blanc, Ts...>; // +/- I suggest to name them as variant<Ts...> : never-empty optionals<Ts...> : possibly empty I believe that the usage of these classes is quite different. 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). While I understand the efficiency trade-offs, this difference in behavior merits IMHO a different name (well if we have several variants ;-). The current C++ proposal design has a hidden error state that IMO is viral and should be fixed. The problem is that with the current language there is no know implementation without using extra memory (as boost::variant does). I would like to see the language modified so that the boost::variant original implementation [1] is well-formed. This implementation would still be less efficient than an possible empty variant that mix empty and error, but the guaranties would be different.
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?
BTW, how eggs::variant<T,T> behaves?
To sum it up, Eggs.Variant is its own thing, but it is way too young for me to know what that thing is yet.
Regards,
No problem, I'm not requesting you to submit your library to Boost. It is just an example of the kind of experimental libraries I would like to see in Boost.[Experimental]. I believe that we need more experimental and basic libraries as yours in Boost. Best, Vicente [1] http://live.boost.org/doc/libs/1_58_0/doc/html/variant/design.html#variant.d...