Re: [boost] [variant2] Andrzej's review

Subject: Re: [boost] [variant2] Andrzej's review
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-04-15 08:18:07

sob., 13 kwi 2019 o 12:45 Niall Douglas via Boost <boost_at_[hidden]>
napisał(a):

> On 13/04/2019 01:34, Andrzej Krzemienski via Boost wrote:
>
> > I recommend that variant2 should be REJECTED in its current shape.
>
> I find this recommendation excessively harsh personally.
>
> I agree that randomly permuting state in order to "avoid" an empty state
> is worse than an empty state.
>
> I just do not understand the antipathy here to a
> double-buffered-by-default design, and thus the strong guarantee can be
> easily made, rather than a worse-than-useless basic guarantee which is
> only technically valid, but is certainly surprising.
>
> I do not find an Expected implementation problematic IF triviality of
> member special function is propagated. It needs to match, exactly, the
> std::expected edition.
>
> In general, I think me and you are thus in general agreement given
> everything you have discussed and the questions you have raised. I think
> therefore an acceptance with required conditions of change is the more
> appropriate recommendation. Reject, in my opinion, is too harsh. Reject
> is for libraries with no hope of salvation in their present form.
> Variant2 in my mind is not that.
>

Thanks for raising this. Indeed, we seem to agree on the desired design of
a variant that is supposed to be an alternative to std::variant. A strong
guarantee, or a "semi-strong" guarantee (If T's assignment isn't strong, we
can just call it). I personally would probably never use it: I never need
this guarantee, but it is consistent, easy to understand, gotcha-free, does
not encourage buggy code, and is sufficiently different from std::variant
to warrant its existence.

We do disagree on the procedural things, though. So let me try to explain.

Regarding the implementation of Expected. I didn't even look at it. I
barely had time to review the Variant. (Thank you, Michael, for extending
the review period.) I trust that Peter's implementation is good. My
objection is not to putting an implementation of std::expected into Boost,
but to hiding it in a library called "Variant". I would rather encourage
Peter to provide it as a dedicated Library, even if this other library says
"it is a variant inside". Even if Expected uses Variant2 inside today it
may change in the future, if additional constraints are imposed on
std::expected, which make no sense for Variant2.

Also, we seem to ave different interpretation of what "Reject" means. I am
following the distinction that I observed in the first days of Boost:
Conditionally accept -- Any reviewing is finished. Get the library in and
just fix this and that, subject to a mini-review, which is just a control
of whether the conditions have been met
Reject and encourage a re-submission -- This is quite similar, except that
we have another formal review.

I think we need another review. Not that we do not trust Peter: far from
it. But given the strong controversy around the exception safety guarantee
for assignment/emplacement, we -- the community -- need the review to
discuss and understand the problem and design space better. To get some
sort of consensus that we can use for promoting and teaching the
boost::variant in a uniform way.

I hope Peter is not discouraged by recommendation.

Regards,
&rzej;