CODEWITHSUNDEEP
c++c++17constexprvariant
user10605163
user10605163

Reputation:

std::variant modification in constexpr

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:

Does not work in either case:

Upvotes: 7

Views: 2243

Answers (1)

Shafik Yaghmour
Shafik Yaghmour

Reputation: 158529

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.

Upvotes: 2

Related Questions