Open joto opened 8 years ago
Yes, should be
noexcept(noexcept(variant<Types...>(std::forward<T>(rhs))) &&
std::is_move_constructible<std::tuple<Types...>>::value)
The first part covers is_constructible<V, T&&> && is_destructible<V>
.
Edit: assignable->constructible, as helper::move calls constructor.
It'd probably be best to dispatch on rvalue-ness of T
, so that it doesn't have to make two moves if T
is an rvalue, but that can be left to a later improvement.
While you're looking at it... the copy-assignment below makes an unnecessary second copy; and it is actually redundant -- the universal covers lvalue references as well.
I don't feel comfortable having such complex code (especially in areas with compiler problems like #86) without any tests. And it is really easy to get the implementation of the function and the noexcept()
clause out of sync. How are we going to test this?
In that case, just remove both conversion-assignment operators, they're not needed -- actually the compiler will generate exactly the code in the first, and better than the second:
v = x; // conversion constructor from decltype(x) must be available
// the compiler will do
v = V(x); // i.e. construct a temporary variant and move-assign =(V&&)
I think the
noexcept
onoperator()
here is wrong. There are several operations involved which all might fail.