Re: [boost] [variant2] Review of Variant2 started today : April 1 - April 10
Andrey Semashev wrote:
Also, IMHO, it's better to have libraries more focused and fine grained. Why not have `expected` as a separate library?
expected<T, E...> is basically a variant, with a slightly different interface.
To expand on that a bit... to implement expected<T, E...> you need an underlying variant. You can either implement your own ad-hoc one, which is a duplication of work; or you could use an existing variant, but then you inherit its properties and have to reflect those in the specification of `expected`. For instance, if the variant can be valueless, you need to figure out what to do in `expected` when it gets into that state. For those reasons, it makes most sense to develop `variant` and `expected` in parallel, as parts of the same library.
On 4/2/19 6:43 AM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
Also, IMHO, it's better to have libraries more focused and fine grained. > Why not have `expected` as a separate library?
expected<T, E...> is basically a variant, with a slightly different interface.
To expand on that a bit... to implement expected<T, E...> you need an underlying variant. You can either implement your own ad-hoc one, which is a duplication of work; or you could use an existing variant, but then you inherit its properties and have to reflect those in the specification of `expected`. For instance, if the variant can be valueless, you need to figure out what to do in `expected` when it gets into that state.
For those reasons, it makes most sense to develop `variant` and `expected` in parallel, as parts of the same library.
I'm thinking more of variant. Then expected, etc become "use cases" rather than first class library types. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 4/2/19 4:43 PM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
Also, IMHO, it's better to have libraries more focused and fine grained. > Why not have `expected` as a separate library?
expected<T, E...> is basically a variant, with a slightly different interface.
To expand on that a bit... to implement expected<T, E...> you need an underlying variant. You can either implement your own ad-hoc one, which is a duplication of work; or you could use an existing variant, but then you inherit its properties and have to reflect those in the specification of `expected`.
This doesn't make sense. You are using the very specific `variant` implementation - the one that is in the same library with `expected`. How is that different, in terms of inheriting properties, from using a `variant` (maybe even the very same `variant` you're using now) from a separate library?
For instance, if the variant can be valueless, you need to figure out what to do in `expected` when it gets into that state.
If you're using a specific version of `variant`, I don't see the problem - that version of `variant` defines the behavior wrt. valueless state.
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. If there is some interface limitation then make the necessary interface in `variant` and make it public. If that is not reasonable then `variant` is not the right underlying component for `expected` (I doubt that's the case, though).
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.
ś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;
participants (4)
-
Andrey Semashev -
Andrzej Krzemienski -
Peter Dimov -
Robert Ramey