Re: [boost] Mother of all Variants

Subject: Re: [boost] Mother of all Variants
From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2019-04-17 08:03:32

> On 16. Apr 2019, at 17:42, Robert Ramey via Boost <boost_at_[hidden]> wrote:
> 
> Right.  We could have it both ways.  That is the mother of all variants could be used to generate a custom type given the requirements.  For those who don't want/need to delve into all the details, we provide a list of specialization for commonly used variants which would probably address 99.9% of users needs.

I haven't participated in the discussion so far, but I think this is the best solution, considering the length of the debate.

Since the solutions have different trade-offs and there is no clear way to argue for one particular trade-off, then it would be the best thing to provide a variant that allows you to chose your trade-off. The library designer can still set the default to whatever he/she feels most comfortable with.

It is true that this potentially requires a lot of additional code to maintain. I nevertheless think that a new boost::variant would have more impact if it could be a catch-all for all the design choices that are floating around on github. There are quite many variants out there.

The purpose of boost, in my view, is to provide a standard solution so that people can stop reinventing the wheel. We already have the std::variant in C++17, which chose a particular trade-off. I don't think it is very helpful if boost just adds another variant with one particular trade-off.

Boost libraries tend to give the developer more choice, and I value that. For example, for the boost::container::vector, I can set the growth factor if I want to. That's great and not provided by the std::vector.

For now, boost::variant2 also has the advantage that it is C++11 instead of C++17, but that advantage will wear off very quickly as time passes and more C++17 capable compilers are used in the field. If boost::variant2 was a mother_of_all_variants (please do not call it really like that), it can have a lasting impact on the C++ community even then.

Best regards,
Hans