Boost logo

Boost :

Subject: Re: [boost] [variant2] Review
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2019-04-16 16:46:54


Jan Herrmann wrote:
> I looked at the review, at the code and some time ago I tried
> to implement my own variant. In my opinion in variant2 the
> individual parts are more worth than the whole. Most
> implementation details would be of great use for implementing
> variants with a differnt trade-off. Hence the library ought
> to be split into several independend parts:
> * a typing switch
> * a variadic union
> * an extendable visitation mechanism
> * a variant view
> * related type traits
> * several implementation of a concrete variant

and Robert Ramey wrote:
> I'm way out of my depth in the variant discussion. Seems to me it
> revolves around all the trade offs regarding design choices. Could we
> perhaps decide not to decide. Suppose we create a type which looks like:
>
> template<
> bool BasicGuaranteeSupported,
> bool StrongGuaranteeSupported,
> bool EmptyStateProhibited,
> bool AssignmentSupported,
> bool MoveSupported,
> class T ...
> >
> struct mother_of_variants{
> // some trivial mp11 code
> };

and in my review I wrote:
> Ideally, perhaps a Boost.Variants *library* should provide a selection
> of different variants with different features?

I believe it's not reasonable or realistic to ask Peter to refactor his code
to the extent that e.g. Robert suggests. But it would be good, as Jan
suggests, to make it easier to build alternative variants by re-using the
"uncontroversial" parts of the Variant2 code. Peter, what do you think
about this? I'm not suggesting that you explicitly make the various
internal components (as listed by Jan) public interfaces, with docs etc.,
but just add enough comments for others to be able to work with it and
perhaps break it into multiple files. A quick example of how to build,
say, a trivial variant with single storage that rejects assignment of types
that might throw, would make it perfect!

Regards, Phil.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk