Re: [boost] [variant2] Review

Subject: Re: [boost] [variant2] Review
From: Robert Ramey (ramey_at_[hidden])
Date: 2019-04-16 18:36:24

On 4/16/19 10:56 AM, Emil Dotchevski via Boost wrote:
> 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. 
Right

> It happens when the expert is so
> uncertain in the most critical design choices 
Right - when concensus on design choices cannot be reached.

that he concludes that
> leaving them to the casual user is a better bet for correctness; 
Hmmm - not sure I'm buying that.
or when a
> committee demands customization as a condition for acceptance.
Right.  Sometimes this is a disaster - C++ intialization and probably 
Modules and Contracts too.  But sometimes it can work out very well. 
It's widely explored in Alexandrescu's seminal book "Modern C++ Design".
I've been happy with the way it has worked out in safe numerics.  I 
think boost.iterators is an example and I think there are others.  Of 
course there are disasters also.

I would disagree that the only alternative is to leave them to the 
"casual user".  There is no reason that a library cannot define the 
common cases for the "casual user" and still expose the the base 
functionality as an "escape hatch" for those of us who are masochists.

  I see this is really a "simple" issue of implementation. Is it less 
work to factor out the commonality of all these types or build each one 
individually from scratch? The only way to know is to actually attempt 
it.  Of course bringing this up at the end of 3 weeks of intense review 
is ... inconvenient.  But it's only that review which reveals the 
problems we have with the one by one approach.

Of course this is really unfair to the library author.  I don't think 
there's any way to get around that and I don't have an answer.  But 
knowing something of the personalities of many the characters involved, 
some part of me is thinking that peter, obsessive intellectual 
exhibitionist that he is,  is already experimenting with idea to see 
whether i might be incorporated or just needs to be killed off.

Robert Ramey

> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>