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