To never-empty or not to never-empty (a.k.a. Design):
In general, since we already have std::variant with the valueless state,
having an alternative that provides never empty guarantee is useful if
only to gain practical experience with both approaches. Again, in
general, I consider never empty guarantee a plus as it reduces the total
number of states of a program, making it easier to reason about and
removing performance overhead.
However, I agree with Andrzej in that the behavior when after an
exception a seemingly random value appears in the variant out of the
thin air is not useful and may even be harmful. I realize that there are
cases when one simply doesn't care about the variant contents after an
exception, but still that kind of uncertainty seems unneeded and
undesired to me. Frankly, in my experience, people (myself included)
often simply forget or don't consider what will happen if assignment
fails, leaving subtle bugs in the code. I would very much prefer to be
explicit about when I allow a different value to appear in the variant.
I think, including monostate in the list of types would be an adequate
way of telling that intention. Meaning that when monostate is *not*
present, I would not expect any funny business from the variant, and
therefore the variant has to use double storage, if it must.
It's disappointing that Boost.Variant2 does not depart from the existing
Boost.Variant in this regard, which kind of diminishes its value. I'm
not saying Boost.Variant design is bad, I'm saying that we already have
it, and a potential new library could offer something different,
something not supported by either std::variant or Boost.Variant, even if
as an option. I guess, there is some value in facelifting Boost.Variant
to the more recent C++ practices and interface closer to std::variant,
which makes learning easier.
Docs:
- In general, the docs are fairly minimal. I think, it could benefit
from more rationale discussion and guidelines for unexperienced users,
like when to use std::variant, Boost.Variant and Boost.Variant2. I
think, the very Boost.Variant2 (and the variant class itself) naming is
unfortunate in this regard, as it could be a hint in itself. There's not
a single usage example in the docs. I think, in the current form docs
are sufficient for experienced programmers who have used some version of
variant in the past, but not so much for new users who are picking their
first variant ever. Some performance numbers would be useful as well,
although not a requirement.
- One important piece of information that is missing in the docs is what
is the behavior if only the second bullet in the Overview is satisfied
and assignment/emplace throws. Specifically, what is the resulting value
of the variant in this case.
- List of supported compilers and minimum C++ version is missing.
- It would be nice to mention whether the double storage is static (i.e.
it always contributes to the variant size) or dynamic.
- In the synopsys, use std::size_t vs. size_t consistently.
- In variant reference description, define that T0 is the first element
of T argument pack.
- The use of Boost.Mp11 in the deference description requires knowledge
of Boost.Mp11, which is unfortunate. It's probably better to use
standard C++ (e.g. C++17 folding expressions, even though the library
itself might be C++11) or plain English.
- I don't understand the description of the "variant(U&& u)"
constructor. "build an imaginary function FUN(Ti) for each alternative
type Ti" - what function, with what effect? Are you trying to say that
the resulting type of the stored value is selected as-if by C++ overload
resolution? I think, it should be phrased better.
- In variant_alternative description, move the variant_alternative