Re: [boost] [variant2] Review

Subject: Re: [boost] [variant2] Review
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2019-04-16 17:56:39

On Tue, Apr 16, 2019 at 9:47 AM Phil Endecott via Boost <
boost_at_[hidden]> wrote:
>
> 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!

This is the policy-based design approach. It happens when the expert is so
uncertain in the most critical design choices that he concludes that
leaving them to the casual user is a better bet for correctness; or when a
committee demands customization as a condition for acceptance.