Hello,
I looked at the review, at the code and some time ago I tried
to implement my own variant. In my opinion in variant2 the
individual parts are more worth than the whole. Most
implementation details would be of great use for implementing
variants with a differnt trade-off. Hence the library ought
to be split into several independend parts:
* a typing switch
* a variadic union
* an extendable visitation mechanism
* a variant view
* related type traits
* several implementation of a concrete variant
1. A typing switch
The typing switch would be provide a litle bit more than (and
can be implementated with help of) mp_with_index.
The following pseudo code shows the implementation idea:
template
constexpr decltype(auto)
typing_switch(size_t index, Function fun, Cast cast, Object obj) {
return fun(cast(integral_constant{}, obj));
}
The object is a variant and the cast transfroms this special variant
to a concrete value (with type). The function is provided by the
variant user. The visit function (line 1732) would become something
like this:
template<class Variant>
struct variant_cast
{
template<class Index>
constexpr decltype (auto) operator()(Index, Variant& V) {
return unsafe_get();
}
};
template
constexpr decltype(auto) visit( F&& f, V1&& v1 )
{
return typing_switch(v.index(), f,
variant_cast<V1>, v1);
}
A simplified deserialisation can be implementated as follows:
template<class Types>
struct index_to_type
{
template<class Index>
constexpr decltype (auto) operator()(Index, std::nullptr_t) {
return mp_identity>{};
}
};
template
Variant deserialize(Archive& ar) {
size_t index;
ar >> index;
Variant f = [&ar](auto type) {
decltype(type)::type concrete_element;
ar >> concrete_element;
return Variant{std::move(concrete_element)};
};
return typing_switch(index, f, index_to_type<Variant>{}, nullptr);
}
With help of this function an implementation of a visitation function
is easy.
2. A varidic union
Without doubt a type implementing a varidaic union is a
building block for almost every variant implementation.
It should be part of the public interface, well tested
and with a minimal interface (get<i> and emplace<i>)
3. An extendable visitation mechanism
This could be used to implement visitation on multiple
different variants. It should use visit on one variant as
customization point.
4. A variant view (and a mutable variant view)
It could have the following form:
template
class variant_view {
void* value;
size_t index;
public:
/* visit ... */
};
It is a little bit like folly/DiscriminatedPtr.h
(https://github.com/facebook/folly/blob/master/folly/DiscriminatedPtr.h)
but without platform specific code. It can be used for functions
which take variants as a const references (or in the mutable form
as variants which can change the value but not the actual type).
It can be constructed from corresponding variants, values (which
are part of T...) and other variant_views. As long as it is constructed
from a variant implemented with the variadic union the process can
be simple: all members of a union have the same address as the union
and the index is equal. For special cases the process can be more
complicated. For other variant_views the transformation can be
implemented as a runtime lookup in an array and for simple values it
is simple.
A variant_view can for example be used for functions accepting const
references like output and serialisation, or for referencing "polymorphic"
objects like nodes in ASTs.
5. Related type traits
Meaningfull type traits which can be used in one variant have a
good chance be be used in a related one. If one variant want to static
assert in case void is one of its types the logic is probably usefull
for others. They should be collected.
6. Several implementation of a concrete variant
This is the place for variant2.
With this building blocks it should be simpler to implement a custom
variant.
Now lets think of a few use cases:
A class contains 3 variants each containing only a few "small" types.
Instead of using 3 variants it could pack all indices into one int
and construct variant_views as needed. This can reduce the size of the
class and saves memory bandwidth. Editing of variants would be of course
more complicated.
A variant containing a few trivial small types which are used in allmost
all cases and one type (T_evil) which is used rarely, is big and can
throw in certain situation. The soloution can be a normal variant with
the exception of storing T_evil as a smart pointer and dereferences it
when visited.
A variant with allocator support. In case a user has a solution (or
idea) for their variant which lives in shared memory a simple blueprint
with generic components like varidic union, a typing switch and useable
type traits may be of help.
I think requirements for different variant types mentioned in the review
could be implemented with some well defined basic building blocks.
Beside these thougths I looked at the library.
expected.hpp:
I tried to compile the following file (containing only one non empty line):
#include
and it does not compile. It should be a self-contained header. Therefore
it should be not part of the library.
variant.hpp:
Personally (in contrast to other reviewers) I would prefer code more
structured in different files. In an ideal world there is for every
component a single header file (in clean C++ 17) with minimal dependencies
which directes for compiler (and version) specific stuff to a different
header. For the future it would result in source code written in newest
standard without disturbing influence from ifdefs caused by old buggy
compilers.
The source has more than 1800 lines with only a few comments, short (1
char) names and very long lines (200 chars and more). For me it is not
easy to read (after clang-format it is 2030 lines). Variant alone has
more than 450 lines of code. With more shorter files the connection of
(and dependencies among) the components would be more visble.
I started at the begining of the file and searched for a testcases for
monostate and I didn't found one. There are a few testcases inside
variant_valueless.cpp which use monostate but none which test it
directly. Next variant_size. There are testcases but most deal with
variants of type 'variant<> const', 'variant<void>' and the like.
Declaring variables of these types results in compile time errors. It is
not wrong std::variant gave me the same result, but it is a kind of
strange that most tests are implemented in terms of variants wich are
ill-formed. On the other hand there are no tests which do not compile.
These are two example which should not compile.
The template detail::variant_alternative_impl looks like something which
copies const, volatile and references. Is there a difference to
copy_cv_ref at the end? Could it be used?
At the end of the file the comparison is implemented. But operator!= is
not implementated in terms of operator== and operator<= and others not
in terms of operator<. In case there is a reason for it documentation
would be nice.
Summarized I think variant2 should NOT be part of boost. I think the
focus should be more on reusable components and better documented code.
I think most of the code could be very usefull with more descriptive
names and test.
Regards Jan Herrmann
