7
votes

Consider the following two programs:

#include<variant>
#include<iostream>

constexpr auto f() {
    using T = std::variant<bool, int>;
    T t(false);
    t = T(true);
    return std::get<bool>(t);
}

template<auto V> 
void print() { std::cout << V << "\n"; }

int main() {
    print<f()>();
}

and

#include<variant>
#include<iostream>

constexpr auto f() {
    using T = std::variant<bool, int>;
    T t(false);
    t = T(42);
    return std::get<int>(t);
}

template<auto V> 
void print() { std::cout << V << "\n"; }

int main() {
    print<f()>();
}

GCC compiles both of these and outputs the expected results. Clang does not compile any of them with the following error message in both cases:

<source>:4:16: error: constexpr function never produces a constant expression [-Winvalid-constexpr]
constexpr auto f() {
               ^
<source>:7:7: note: non-constexpr function 'operator=' cannot be used in a constant expression
    t = T(42);
      ^
/opt/compiler-explorer/gcc-8.2.0/lib/gcc/x86_64-linux-gnu/8.2.0/../../../../include/c++/8.2.0/variant:1095:16: note: declared here
      variant& operator=(variant&&) = default;

Are the two programs well-formed? If not, why?

Also if they are not well-formed, is the error message Clang gives appropriate? According to [variant.assign] the move assignment operator should be constexpr.

Furthermore according to (7.4) the assignment in the second example should behave equivalent to emplace<int>(...) which is not declared constexpr ([variant.mod]). Does this imply the second example is ill-formed because the template argument cannot be evaluated as constant expression or does the wording allow/require this behavior?

EDIT:

Based on the comments it seems that Clang compiles and ouputs the correct results if libc++ is used and the error occurs only with libstdc++. Is this an incompatibility between the standard library and compiler?

On https://godbolt.org/:

Works in both cases:

  • GCC 8.2.0 "-std=c++17"
  • Clang 7.0.0 "-std=c++17 -stdlib=libc++"

Does not work in either case:

  • Clang 7.0.0 "-std=c++17"
1
cannot reproduce; which versions of g++ and clang++ are you using?max66
What if you use -stdlib=libc++Shafik Yaghmour
Looks like your library has a bug as variant& operator=(variant&&) = default; should be constexpr variant& operator=(variant&&) = default;NathanOliver
clang accepts it with libc++ Demo.Jarod42
Not an answer but similar clang bug reportJans

1 Answers

2
votes

This looks like a clang bug we can see from the libstdc++ variant header that the move assignment operator is indeed not marked constexpr:

variant& operator=(variant&&) = default;

but a defaulted and implicitly defined move assignment operator can still be constexpr, we can see this from [class.copy.assign]p10 (emphasis mine):

A copy/move assignment operator for a class X that is defaulted and not defined as deleted is implicitly defined when it is odr-used ([basic.def.odr]) (e.g., when it is selected by overload resolution to assign to an object of its class type), when it is needed for constant evaluation ([expr.const]), or when it is explicitly defaulted after its first declaration. The implicitly-defined copy/move assignment operator is constexpr if

  • (10.1) X is a literal type, and
  • (10.2) the assignment operator selected to copy/move each direct base class subobject is a constexpr function, and
  • (10.3) for each non-static data member of X that is of class type (or array thereof), the assignment operator selected to copy/move that member is a constexpr function.

From what I can can tell the libstdc++ implementation should fit all these cases, it is a literal type, it does not have non static data members and the assignment operator for all its bases should be constexpr as well.