How to solve the issue of "read of non-constexpr variable 'a' is not allowed in a constant expression" with boost.hana

Question

I'm using c++17 with Boost.hana to write some meta-programming programs. One issue stuck me is what kind of expression can be used in a constexpr context like static_assert. Here is an example:

#include <boost/hana.hpp>

using namespace boost::hana::literals;

template <typename T>
class X {
public:
    T data;

    constexpr explicit X(T x) : data(x) {}

    constexpr T getData() {
        return data;
    }
};


int main() {
    {   // test1
        auto x1 = X(1_c);
        static_assert(x1.data == 1_c);
        static_assert(x1.getData() == 1_c);
    }
    {   //test2.1
        auto x2 = X(boost::hana::make_tuple(1_c, 2_c));
        static_assert(x2.data[0_c] == 1_c);

        // static_assert(x2.getData()[0_c] == 1_c); // read of non-constexpr variable 'x2' is not allowed in a constant expression
    }
    {   //test2.2
        auto x2 = X(boost::hana::make_tuple(1_c, 2_c));
        auto data = x2.getData();
        static_assert(data[0_c] == 1_c);
    }
}

First I write a class X with a field data and an accessor getData(). In the main()'s test1 part, x1.data and x1.getData() behave same as I expected. But in the test2 part, changing the argument to a boost::hana's tuple, static_assert(x2.data[0_c] == 1_c) still behaves fine but static_assert(x2.getData()[0_c] == 1_c) fails compilation, with error of 'read of non-constexpr variable 'x2' is not allowed in a constant expression'. What weired is if I split x2.getData()[0_c] into auto data = x2.getData(); and static_assert(data[0_c] == 1_c); it compiles fine again. I'd expect they behave the same. So can anyone help explain why x2.getData()[0_c] can not be used in static_assert in this example?

To reproduce: clang++8.0 -I/path/to/hana-1.5.0/include -std=c++17 Test.cpp

Answer 1

The problem is that boost::hana::tuple does not have a copy constructor.

It has a constructor that looks like a copy constructor:

template <typename ...dummy, typename = typename std::enable_if<
    detail::fast_and<BOOST_HANA_TT_IS_CONSTRUCTIBLE(Xn, Xn const&, dummy...)...>::value
>::type>
constexpr tuple(tuple const& other)
    : tuple(detail::from_index_sequence_t{},
            std::make_index_sequence<sizeof...(Xn)>{},
            other.storage_)
{ }

But since this is a template, it is not a copy constructor.

Since boost::hana::tuple does not have a copy constructor, one is declared implicitly and defined as defaulted (it is not suppressed since boost::hana::tuple does not have any copy or move constructors or assignment operators, because, you guessed it, they cannot be templates).

Here we see implementation divergence, demonstrated in the behavior of the following program:

struct A {
    struct B {} b;
    constexpr A() {};
    // constexpr A(A const& a) : b{a.b} {}    // #1
};
int main() {
    auto a = A{};
    constexpr int i = (A{a}, 0);
}

gcc accepts, while Clang and MSVC reject, but accept if line #1 is uncommented. That is, the compilers disagree on whether the implicitly-defined copy constructor of a non-(directly-)empty class is permissible to use within constant-evaluation context.

Per the definition of the implicitly-defined copy constructor there is no way that #1 is any different to constexpr A(A const&) = default; so gcc is correct. Note also that if we give B a user-defined constexpr copy constructor Clang and MSVC again accept, so the issue appears to be that these compilers are unable to track the constexpr copy constructibility of recursively empty implicitly copyable classes. Filed bugs for MSVC and Clang (fixed for Clang 11).

Note that the use of operator[] is a red herring; the issue is whether the compilers allow the call to getData() (which copy-constructs T) within a constant-evaluation context such as static_assert.

Obviously, the ideal solution would be for Boost.Hana to correct boost::hana::tuple such that it has actual copy/move constructors and copy/move assignment operators. (This would fix your use case since the code would be calling user-provided copy constructors, which are permissible in constant-evaluation context.) As a workaround, you could consider hacking getData() to detect the case of non-stateful T:

constexpr T getData() {
    if (data == T{})
        return T{};
    else
        return data;
}

Answer 2

The issue is because you are trying to retrieve a run time value and test it at compilation.

What you can do is to force the expression at compile time through a decltype and it will work like a charm :).

static_assert(decltype(x2.getData()[0_c]){} == 1_c);

#include <boost/hana.hpp>

using namespace boost::hana::literals;

template <typename T>
class X {
public:
    T data;

   constexpr explicit X(T x) : data(x) {}

   constexpr T getData() {
        return data;
    }
};


int main() {
    {   // test1
        auto x1 = X(1_c);
        static_assert(x1.data == 1_c);
        static_assert(x1.getData() == 1_c);
    }
    {   //test2
        auto x2 = X(boost::hana::make_tuple(1_c, 2_c));
        static_assert(x2.data[0_c] == 1_c);

         static_assert(decltype(x2.getData()[0_c]){} == 1_c);

        auto data = x2.getData();
        static_assert(data[0_c] == 1_c);
    }
}

Now the expression is evaluated at compile time, so the type is known at compile time and since it is constructible at compute time also, it is possible to use it within a static_assert