Subject: Re: [boost] [variant2] Review Results
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-05-11 06:47:22
Congratulations Peter for getting variant2 into Boost! And thanks to
Michael for managing the review.
The review itself was very educational. I also believe that the reviews are
one of the most valuable things that Boost offers to the community.
I agree that a strong (or "semi-strong") guarantee for variant is
uncontroversial and will be found superior to std::variant or
boost::variant in a number of cases.
I sustain my offer to provide the introduction page for the documentation,
if this is needed.
Thanks Peter for your contribution to Boost.
sob., 11 maj 2019 o 07:17 Michael Caisse via Boost <boost_at_[hidden]>
> First, I would like to apologize to Peter and the those who took time to
> review Boost.Variant2 for the slow turn-around of a result.
> Thank you Peter for producing and submitting such a high-quality library
> for review. The code has been a pleasure to read and review.
> Thank you to the reviewers! Your participation in the process is what
> makes Boost libraries high-quality. I personally appreciate the time and
> effort that each of you have put into this review.
> Boost.Variant2 will be ACCEPTED after the following changes are made. An
> additional review will not be required.
> - The library will implement the strong guarantee:
> - If all alternatives have nothrow move, single buffer
> - else, double buffer
> - Improved documentation:
> - Addition of a tutorial
> - Addition of design motivation
> - Peter has indicated that triviality propagation will come in a
> future version. The initial Boost release need not support
> triviality propagation.
> - Expected will not be included but may be submitted for review at
> another time.
> Review Verdicts
> The following people provided reviews.
> Reject ----------
> Andrezj Krzemienski
> Antony Polukhin
> Jan Herrmann
> Accept ----------
> Emil Dotchevski
> Gavin Lambert
> Phil Endecott
> Conditionally Accept --------
> Bjorn Reese
> Andrey Semashev
> Damian Jarek
> Niall Douglas
> Andrezj and Antonyâs rejections were based on not having a
> valueless-by-exception state. Neither saw the selected design space
> worth considering and each believed the trade-off was dangerous for users.
> The Conditional Acceptance reviews voiced the following:
> - Strong preference for the strong guarantee (and therefore no need to
> provide âsurprisingâ behaviour for the state after an exception.)
> - Improved documentation containing both tutorial and motivation
> - Triviality propagation of the variant types.
> - Accepted without expected being contained.
> Some Thoughts
> There was a good amount of healthy discussion on the Developer Mail List
> concerning Variant2. I want to thank all of the participants for
> engaging with civility and keeping to the technical merits despite the
> galvanized opinions concerning valueless-by-exception and the basic
> exception guarantee. Over the past couple weeks I have re-read all of
> the discussion threads 3 or 4 times. While some people didnât find value
> in the exchanges, this level of engagement about design trade-offs is
> one of the attributes that sets Boost reviews apart. They are not merely
> reviews discussing the quality of implementation but also the
> intricacies of design choices within the constraints and consistency of
> the language. When reviewers articulate their opinions the entire
> community learns and grows.
> The trade-offs that Peter made seem dangerous to some yet the exact
> correct formulation for others. There are even standard library
> implementers that donât agree with std::variantâs
> valueless-by-exception. A high-quality variant that provides the strong
> exception guarantee is a type that has been missing from the programmer
> toolbox. Variant2 provides this.
> I will make an additional announcement to the community when the
> conditions for acceptance have been met.
> Thank you all for making Boost better!
> Michael Caisse
> Ciere Consulting
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk