Re: [boost] [variant] Maintainer

Subject: Re: [boost] [variant] Maintainer
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-06-28 04:38:02

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.
>
> 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 
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.design.never-empty.memcpy-solution