śr., 3 kwi 2019 o 20:04 Peter Dimov via Boost <boost@lists.boost.org> napisał(a):
Andrey Semashev wrote:
For those reasons, it makes most sense to develop `variant` and `expected` in parallel, as parts of the same library.
Sorry, I don't see why the two components need to be implemented in the same library and not use one another like a normal user would.
It's not clear what you're arguing for, or against.
In my opinion, it's better to develop these two specific components in the same library, both from physical design and logical point of view. So that's what I've been doing, and your not seeing why that should be doesn't change my opinion.
So if you're arguing that I should do something else, I don't agree.
If, on the other hand, you're arguing that `expected<T, E...>` should not get into Boost without a review, that's a legitimate position and if other reviewers feel the same way, and the review verdict states that as an acceptance condition, I will respect that decision, remove `expected` from Variant2 and never add it back.
I think it is a bit unfortunate that we learn about the plan to have two components in one library only during the review. The message from Michael said it was not considered for the review, but it was not clear that you want to put it into the same library. I am not even sure how such subsequent review would look like. We would answer the question if it is good to put another component into the existing library? Here is my concern. When you say that the two components share the same implementation, it means to me that you have chosen the same design trade-offs for them. It is possible that these trade-offs are not good for a general purpose `variant`, but because they work well for `expected<>` variant will also get them. Suppose that variant2 is accepted with its current trade-offs. Then, at some point we get the review or `expected` and the review says that you need to change the design trade-offs for `expected` in order to pass the review. Will you also go back and change the design trade-offs for the already accepted variant2 because the two have to share the same implementation? Maybe a better approach would be to review `expected` first, and sell `variant2` as a secondary tool in that library. I think we have a precedent for this. boost::lexical_cast offers boost::convert::try_lexical_cast, which to me is more useful; Boost.Serialization offers BOOST_STATIC_WARNING. Boost.Spirit offers a faster alternative to `any`. Regards, &rzej;