On 16. Apr 2019, at 17:42, Robert Ramey via Boost
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