Re: [boost] Review request for variant2, review manager wanted

Subject: Re: [boost] Review request for variant2, review manager wanted
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-02-22 22:15:52

> 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