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@lists.boost.org> 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.
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
that he concludes that 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