If anyone would like to step forward to manage the review, please do.
Thanks for the answers to questions on Slack earlier. Firstly, in my opinion this would be a great addition to Boost. It has a very high quality implementation, good documentation, and solves an important problem. My own personal issues with this library as currently presented: 1. I need to know, from reading the documentation, what cost benefit there is to choosing this library over the major STL std::variant's, and Boost.Variant in these areas: a) Build time impact for small and medium sized variants doing a reasonable set of operations. b) Run time impact, for the same operations. c) Optional: also for large sized variants, just so we have evidence to prove to people don't do large sized variants! d) Optional: also compare to Outcome, I obviously have a vested curiosity. 2. I see that triviality of destruction is preserved, indeed half the variant header is just to implement triviality of destruction propagation. However the other individual operations do not have their triviality preserved, so for example if all the types in the variant have a trivial copy assignment but a non-trivial copy constructor, then so ought the variant. The same would go for noexcept-ness, if all the move assignments for all the types in the variant are noexcept, then so should be the variant's. And so on. I appreciate that this is a royal pain in the ass to implement for a never-empty guaranteed variant. I know this because I implemented this for Outcome, and most of the reason that Outcome demands C++ 14 is precisely because I made implementation easy on myself using partial fragment inheritance which ICEs older compilers. You could use the same technique to reduce the implementation burden, though probably with the same cost of dropping usefulness on older compilers. But I do think it's important for high quality codegen for triviality and noexcept to be propagated for all regular operations (including swap), though I do appreciate that the build time impact for implementing this is non-trivial. WG21 also felt this important, and it was remedied in the standard: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0602r4.html 3. I did find it a bit sad that Concepts aren't used when available. It could improve build time impact a bit. But it's no showstopper for me. Anyway, if you agree to implement items 1 and 2 above, I volunteer to act as review manager, if you can't find anyone more suitable. Niall