Boost logo

Boost :

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
> 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 list run by bdawes at, gregod at, cpdaniel at, john at