Re: [boost] [variant2] Review of Variant2 started today : April 1 - April 10

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.