Boost logo

Boost :

Subject: Re: [boost] [variant2] Review of Variant2 started today : April 1 - April 10
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2019-04-02 14:40:59

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).

Boost list run by bdawes at, gregod at, cpdaniel at, john at