CODEWITHSUNDEEP
c++language-lawyerconstexprc++17if-constexpr
Benjamin Buch
Benjamin Buch

Reputation: 6123

not-constexpr variable in if constexpr – clang vs. GCC

struct A{
    constexpr operator bool()const{ return true; }
};

int main(){
    auto f = [](auto v){ if constexpr(v){} };
    A a;
    f(a);
}

clang 6 accepts the Code, GCC 8 rejects it with:

$ g++ -std=c++17 main.cpp
main.cpp: In lambda function:
main.cpp:6:37: error: 'v' is not a constant expression
  auto f = [](auto v){ if constexpr(v){} };
                                     ^

Who is correct and why?

When I take the parameter per reference, both reject the code:

struct A{
    constexpr operator bool()const{ return true; }
};

int main(){
    auto f = [](auto& v){ if constexpr(v){} };
    constexpr A a;
    f(a);
}

Compiled with clang 6:

$ clang++ -std=c++17 main.cpp
main.cpp:6:40: error: constexpr if condition is not a constant expression
    auto f = [](auto& v){ if constexpr(v){} };
                                       ^
main.cpp:8:6: note: in instantiation of function template specialization 
    'main()::(anonymous class)::operator()<const A>' requested here
    f(a);
     ^
1 error generated.

When I copy the parameter into a local variable both accept the code:

struct A{
    constexpr operator bool()const{ return true; }
};

int main(){
    auto f = [](auto v){ auto x = v; if constexpr(x){} };
    A a;
    f(a);
}

Edit: I am sure that the second and third cases will be handled correctly by both compilers. I don't know what the rule is, though.

In the first case I suspect that clang is right, because the case resembles the second. I would like to know if in the first case clang or GCC is correct and which rules in the second case makes the use of the not-constexpr variable v invalid and in the third case x valid.

Edit 2: First Question is clear now: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84421

clang was right, GCC 7 accepted the code as well. The bug will be fixed in the final version of GCC 8.

Upvotes: 4

Views: 599

Answers (1)

Richard Smith
Richard Smith

Reputation: 14158

Clang is correct in all cases. [Full disclosure: I'm a Clang developer]

The question in all cases reduces to this: can we call a constexpr member function on v within a constant expression?

To answer this question, we need to look at [expr.const]p2, which says:

An expression e is a core constant expression unless the evaluation of e, following the rules of the abstract machine (6.8.1), would evaluate one of the following expressions:

  • ...
  • an id-expression that refers to a variable or data member of reference type unless the reference has a preceding initialization and either
    • it is initialized with a constant expression or
    • its lifetime began within the evaluation of e;
  • ...

None of the other rules prohibit any of your examples. In particular, you are allowed to name local variables in a constant expression if they are not of reference type. (You are not allowed to perform lvalue-to-rvalue conversions on them -- that is, read their values -- unless their value is known (for instance, because they're constexpr), and you're not allowed to end up referring to the address of such a variable, but you are allowed to name them.)

The reason that the rules are different for entities of reference type is that merely naming an entity of reference type causes the reference to be immediately resolved, even if you don't do anything with the result, and resolving a reference requires knowing what it's bound to.

So: the first example is valid. The *this value of the constexpr member function is bound to the local variable a. It doesn't matter that we don't know what object that is, because the evaluation doesn't care.

The second example (where v is of reference type) is ill-formed. Merely naming v requires resolving it to the object it's bound to, which can't be done as part of the constant expression evaluation because we have no idea what it'll end up being bound to. It doesn't matter that the later evaluation steps won't use the resulting object; references are resolved immediately when they're named.

The third example is valid for the same reason as the first. Notably, the third example remains valid even if you change v to be of reference type:

auto f = [](auto &v) { auto x = v; if constexpr (x) {} };
A a;
f(a);

... because x is, once again, a local variable that we can name within a constant expression.

Upvotes: 6

Related Questions