sob., 13 kwi 2019 o 12:45 Niall Douglas via Boost
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;