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

pt., 5 kwi 2019 o 02:00 Peter Dimov via Boost napisał(a):

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 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.

Does this happen *only* when `monostate` is at index 0, or when `monostate` is at any index? I thought from the sources that `monostate` on any index gives the guarantee.

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`, 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.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost