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: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-04-05 09:14:00

pt., 5 kwi 2019 o 02:00 Peter Dimov via Boost <boost_at_[hidden]>
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<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.
>

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<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.
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>