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
it.
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: http://eggs-cpp.github.io/variant/index.html
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
https://github.com/pdimov/variant2/blob/develop/doc/expected.md.)
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.