Consider the following code:
struct A {
constexpr operator int() { return 42; }
};
template
void foo() {}
void bar(A a) {
foo(
I would say that Clang is correct.
Draft for current C++ (n4296) says:
14.3.2 Template non-type arguments [temp.arg.nontype]
A template-argument for a non-type template-parameter shall be a converted constant expression (5.20) of the type of the template-parameter
And 5.20 §4 says (emphasize mine):
5.20 Constant expressions [expr.const]
...
(4) A converted constant expression of type T is an expression, implicitly converted to type T, where the converted expression is a constant expression and the implicit conversion sequence contains only
(4.1) — user-defined conversions, ...
IFAIK in foo<a>();
a is converted to int with a constexpr user-defined conversion and as such is a converted constant expression.
That being said, we are not far from a edge case here, and my advice would be: do not play with such a construct in production code :-)
The user-defined conversion is allowed by [expr.const]/(4.1), and I don't see a single applicable bullet point in [expr.const]/2 that would prevent your expression from being a constant one. In fact, the requirements are so loose that declaring a
as
A a;
is still giving a well-formed program, even if a
didn't have a constexpr
default constructor etc., since the conversion operator is constexpr
and no members are evaluated.
As you saw yourself, GCC is contradictory in that it allows a
in the static_assert
condition but not a template-argument.
As @Jarod42 suggests a
should be constexpr
. This is because templates are deduced at compile time, and so non-type arguments also have to be available at compile time. constexpr
is a promise that they will be available at compile time.