4
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.

Benjamin Buch
  • 4,752
  • 7
  • 28
  • 51
  • 1
    Are you asking if `v` is a constant expression or why a non-constant expression can't be used where one is required? What research have you done on the subject? – user167921 Feb 16 '18 at 12:28
  • 1
    I expect Clang to be right. You could, for example, pass in a `std::bool_constant` which, while not `constexpr` itself, has a `constexpr` conversion operator to `bool`. – Quentin Feb 16 '18 at 13:01
  • Seems like a dupe of [this](https://stackoverflow.com/q/47696686/2069064)? – Barry Feb 16 '18 at 13:06
  • Yes, looks very similar, thanks! – Benjamin Buch Feb 16 '18 at 13:16
  • Possible duplicate of [Generic lambda and its argument as constant expression](https://stackoverflow.com/questions/47696686/generic-lambda-and-its-argument-as-constant-expression) – Benjamin Buch Feb 16 '18 at 19:35
  • @BenjaminBuch: I don't think it is a duplicate, that one centered on the function call inside the lamdba (and the argument was known to not be `constexpr`) – Ben Voigt Feb 16 '18 at 19:44
  • @BenVoigt: In my question a (explicitly) constexpr conversion operator to bool is called, in the referred a (implicitly) constexpr copy constructor; the rules should be the same if I understand it right. :-/ – Benjamin Buch Feb 16 '18 at 21:58
  • @BenjaminBuch: In the other one, the argument to that function is not used. Hence the function result is expected to be constexpr even though the argument is not. – Ben Voigt Feb 16 '18 at 22:58

1 Answers1

6

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.

Richard Smith
  • 13,696
  • 56
  • 78