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
is basically a variant, with a slightly different interface. To expand on that a bit... to implement expected
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).