Implementing is_constexpr_copiable - c++

Question

I tried to implement a value template similar to std::is_constructible with the exception to only be true when the type is copiable in a constexpr environment (i.e. its copy constructor is constexpr qualified). I arrived at the following code:
#include <type_traits>
struct Foo {
constexpr Foo() = default;
constexpr Foo(const Foo&) = default;
};
struct Bar {
constexpr Bar() = default;
Bar(const Bar&);
};
namespace detail {
template <int> using Sink = std::true_type;
template<typename T> constexpr auto constexpr_copiable(int) -> Sink<(T(T()),0)>;
template<typename T> constexpr auto constexpr_copiable(...) -> std::false_type;
}
template<typename T> struct is_constexpr_copiable : decltype(detail::constexpr_copiable<T>(0)){ };
static_assert( is_constexpr_copiable<Foo>::value, "");
static_assert(!is_constexpr_copiable<Bar>::value, "");
Now I ask myself if this is according to standard, since compilers seem to disagree about the output.
https://godbolt.org/g/Aaqoah
Edit (c++17 features):
While implementing the somewhat different is_constexpr_constructible_from, with c++17's new auto non-type template type, I once again found a difference between compilers, when dereferencing a nullptr in a constexpr expression with SFINAE.
#include <type_traits>
struct Foo {
constexpr Foo() = default;
constexpr Foo(const Foo&) = default;
constexpr Foo(const Foo*f):Foo(*f) {};
};
struct Bar {
constexpr Bar() = default;
Bar(const Bar&);
};
namespace detail {
template <int> struct Sink { using type = std::true_type; };
template<typename T, auto... t> constexpr auto constexpr_constructible_from(int) -> typename Sink<(T(t...),0)>::type;
template<typename T, auto... t> constexpr auto constexpr_constructible_from(...) -> std::false_type;
}
template<typename T, auto... t> struct is_constexpr_constructible_from : decltype(detail::constexpr_constructible_from<T, t...>(0)){ };
constexpr Foo foo;
constexpr Bar bar;
static_assert( is_constexpr_constructible_from<Foo, &foo>::value, "");
static_assert(!is_constexpr_constructible_from<Foo, nullptr>::value, "");
static_assert(!is_constexpr_constructible_from<Bar, &bar>::value, "");
int main() {}
https://godbolt.org/g/830SCU
Edit: (April 2018)
Now that both compiler supposedly have support for C++17, I have found the following code to work even better (does not require a default constructor on `T`), but only on clang. Everything is still the same but replace the namespace `detail` with the following:
namespace detail {
template struct Sink {};
template constexpr auto sink(S) -> std::true_type;
template constexpr auto try_copy() -> Sink;
template constexpr auto constexpr_copiable(int) -> decltype(sink(std::declval,0)>>()));
template constexpr auto constexpr_copiable(...) -> std::false_type;
}
https://godbolt.org/g/3fB8jt
This goes very deep into parts of the standard about unevaluated context, and both compilers refuse to allow replacing `const T*` with `const T&` and using `std::declval()` instead of the `nullptr`-cast. Should I get confirmation that clang's behaviour is the accepted standardized behaviour, I will lift this version to an answer as it requires only exactly what has been asked.
Clang accepts some undefined behaviour, dereferencing nullptr, in the evaluation of an unevaluated operand of decltype.

Answer 1

The toughest of the challenges, giving a single function evaluating whether a constexpr constructor from const T& exists for arbitrary T, given here seems hardly possible in C++17. Luckily, we can get a long way without. The reasoning for this goes as follows:
Knowing the problem space
The following restrictions are important for determining if some expression can be evaluated in constexpr content:
To evaluate the copy constructor of T, a value of type const T& is needed. Such a value must refer to an object with active lifetime, i.e. in constexpr context it must refer to some value created in a logically enclosing expression.
In order to create this reference as a result of temporary promotion for arbitrary T as we would need to know and call a constructor, whose arguments could involve virtually arbitrary other expressions whose constexpr-ness we would need to evaluate. This looks like it requires solving the general problem of determining the constexprness of general expressions, as far as I can understand. ¹
¹ Actually, If any constructor with arguments, including the copy constructor, is defined as constexpr, there must be some valid way of constructing a T, either as aggregate initialization or through a constructor. Otherwise, the program would be ill-formed, as can be determined by the requirements of the constexpr specifier §10.1.5.5:
For a constexpr function or constexpr constructor that is neither defaulted nor a template, if no argument values exist such that an invocation of the function or constructor could be an evaluated subexpression of a core constant expression, or, for a constructor, a constant initializer for some object ([basic.start.static]), the program is ill-formed, no diagnostic required.
This might give us a tiny loophole.²
So the expression best be an unevaluated operand §8.2.3.1
In some contexts, unevaluated operands appear ([expr.prim.req], [expr.typeid], [expr.sizeof], [expr.unary.noexcept], [dcl.type.simple], [temp]).
An unevaluated operand is not evaluated
Unevaluated operands are general expressions but they can not be required to be evaluatable at compile time as they are not evaluated at all. Note that the parameters of a template are not part of the unevaluated expressiont itself but rather part of the unqualified id naming the template type. That was part of my original confusion and tries in finding a possible implementation.
Non-type template arguments are required to be constant expressions §8.6 but this property is defined through evaluation (which we have already determined to not be generally possible). §8.6.2
An expression e is a core constant expression unless the evaluation of e, following the rules of the abstract machine, would [highlight by myself] evaluate one of the following expressions:
Using noexpect for the unevaluated context has the same problem: The best discriminator, inferred noexceptness, works only on function calls which can be evaluated as a core-constant expression, so the trick mentionend in this stackoverflow answer does not work.
sizeof has the same problems as decltype. Things may change with concepts.
The newly introduced if constexpr is, sadly, not an expression but a statement with an expression argument. It can therefore not help enforce the constexpr evaluatability of an expression. When the statement is evaluated, so is its expression and we are back at the problem of creating an evaluatable const T&. Discarded statements have not influence on the process at all.
Easy possibilities first
Since the hard part is creating const T&, we simply do it for a small number of common but easily determined possibilities and leave the rest to specialization by extremely special case callers.
namespace detail {
template <int> using Sink = std::true_type;
template<typename T,bool SFINAE=true> struct ConstexprDefault;
template<typename T>
struct ConstexprDefault<T, Sink<(T{}, 0)>::value> { inline static constexpr T instance = {}; };
template<typename T> constexpr auto constexpr_copiable(int) -> Sink<(T{ConstexprDefault<T>::instance}, 0)>;
template<typename T> constexpr auto constexpr_copiable(...) -> std::false_type;
}
template<typename T>
using is_constexpr_copyable_t = decltype(detail::constexpr_copiable<T>(0));
Specializing details::ConstexprDefault must be possible for any class type declaring a constexpr copy constructor, as seen above. Note that the argument does not hold for other compound types which don't have constructors §6.7.2. Arrays, unions, references and enumerations need special considerations.
A 'test suite' with a multitude of types can be found on godbolt. A big thank you goes to reddit user /u/dodheim from whom I have copied it. Additional specializations for the missing compound types are left as an exercise to the reader.
² or What does this leave us with?
Evaluation failure in template arguments is not fatal. SFINAE makes it possible to cover a wide range of possible constructors. The rest of this section is purely theoretical, not nice to compilers and might otherwise be plainly stupid.
It is potentially possible to enumerate many constructors of a type using methods similar to magic_get. Essentially, use a type Ubiq pretending to be convertible to all other types to fake your way through decltype(T{ ubiq<I>()... }) where I is a parameter pack with the currently inspected initializer item count and template<size_t i> Ubiq ubiq() just builds the correct amount of instances. Of course in this case the cast to T would need to be explicitely disallowed.
Why only many? As before, some constexpr constructor will exist but it might have access restrictions. This would give a false positive in our templating machine and lead to infinite search, and at some time the compiler would die :/. Or the constructor might be hidden by an overload which can not be resolved as Ubiq is too general. Same effect, sad compiler and a furious PETC (People for the ethical treatment of compilers™, not a real organization). Actually, access restrictions might be solvable by the fact that those do not apply in template arguments which may allow us to extract a pointer-to-member and [...].
I'll stop here. As far as I can tell, it's tedious and mostly unecessary. Surely, covering possible constructor invocations up 5 arguments will be enough for most use cases. Arbitrary T is very, very hard and we may as well wait for C++20 as template metaprogramming is once again about to change massively.