Boost logo

Boost :

Subject: Re: [boost] [variant2] Review of Variant2 started today : April 1 - April 10
From: Peter Dimov (pdimov_at_[hidden])
Date: 2019-04-04 23:59:20

The following is my attempt to give a high-level answer to the questions
raised so far.

* First, the submission is a variant type that provides the basic exception
safety guarantee and the "never-empty" guarantee. "Never empty", in this
context, has the specific meaning that variant<T1, T2, ..., Tn> has an
invariant that it always contains a valid object of one of the given types
T1, T2, ..., Tn, and is not allowed any other state.

A possibly-empty variant can be well approximated by adding `monostate` as
one of the alternatives. This is recognized by `variant` as the empty state,
and is preferentially used as a fallback on exception. If monostate is the
first alternative, as is the common case, variant will default-construct to

The variant design space is fairly well known, and has been sufficiently
explored. Possibly-empty variants (a perfectly legitimate design option)
exist. Here is one:

However, the type under review is what it is. I understand that everybody
has his own preference on design matters, but I've made my choice, and this
is what is being reviewed.

* Second, the submission contains a variant-like type `expected<T, E...>`,
which at this point does not meet the review criteria of having a test
suite, and a finished documentation. (The unfinished documentation is at

I decided to request the review at this time because variant<> is ready for
use, and providing it in Boost seemed more practical (people could take
advantage of it) than blocking it until I find the time to finish
`expected`. And I didn't remove `expected` from the submission in order to
allow reviewers to take a look at it and express a preference, if they so
choose, on what they feel its fate ought to be.

Traditionally, once libraries are accepted, we don't hold a review on each
subsequent addition. But an advance warning couldn't hurt.

So, in your review, you can state what you want done with `expected`. If the
submission is accepted in its entirety, I will finish the `expected` test
suite and documentation before adding the library to Boost. Or, if the
submission is accepted on the condition `expected` not be added without a
review, I will remove it before adding the library, and not add it later
without a review.

Boost list run by bdawes at, gregod at, cpdaniel at, john at