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-03 20:57:03

śr., 3 kwi 2019 o 20:04 Peter Dimov via Boost <boost_at_[hidden]>
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;