title: Is a compiler forced to reject invalid constexpr?
body: <pre><code>#include &lt;exception&gt;
  
  constexpr bool foo(bool x)
  {
    return x ? true : throw std::exception();
  }
  
  int main()
  {
    // 1) must never be compiled
    // static_assert(foo(false), "");
  
    // 2) must always be compiled?
    const bool x = foo(false);
  
    // 3) must never compile?
    constexpr bool y = foo(false);
  
    return 0;
  }
  </code></pre>
  
  <p>I'm sure that (1) must lead to a compile error. I'm quite sure that (2) must not be rejected at compile time, though it will fail at runtime.</p>
  
  <p>The interesting case is the constexpr variable (3). In this simple example, gcc and clang actually evaluate the expression, and will therefore reject the program. (Error message: y is not a constant expression).</p>
  
  <p>Is every C++11 compiler forced to reject the program? What if foo(false) was replaced by a more complex expression?</p>
  
  <p>I was suprised to find out that constexpr were not turing-complete, though it will be after a change in the specification:
  <a href="https://stackoverflow.com/questions/9201506/is-constexpr-based-computation-turing-complete">Is constexpr-based computation Turing complete?</a></p>
  
  <p>Maybe this is related to my question. As far as I understand, the compiler is allowed to postpone the actual evaluation of the constexpr (3) in this example until runtime. But if constexpr are turing-complete, I find it hard to believe that the compiler can decide for all constexpr whether an exception will be thrown (which means that the constexpr is invalid).</p>