How so? constexpr doesn't guarantee that an expression is evaluated at compile time, but it does guarantee that it could be.

> but it does guarantee that it could be.

in which sense do you mean this? consider for instance

    constexpr int foo(int x) 
    { if(x < 0) throw "error"; return x; }

I would say that "guarantee that it could be" means that as long as the function definition itself "builds" / is validated by the compiler, you can use it in a constexpr context yet this is not the case here:

    constexpr int a = foo(123); // works fine
    constexpr int b = foo(-123); // compile error
    int c = foo(-123); // works fine

so having "constexpr" in the API does not mean that your code will always build ; as soon as you have constexpr the entire implementation of the function is part of the API, thus making the keyword moot like gpderetta says

Yup. Turns out, I was wrong.

That's what everybody originally believes (me included)!

   constexpr is_right_answer(int x){
      if (x==42) return true;
      else {
        std::cout <<"try again \n";
        return false;
  }

A function can be constexpr as long as at least one possible invocation can be compile time evaluated. In fact compilers can't generally prove that a function can't be constexpr.

I believe consteval has the semantics you want but I've yet to study it in details.

For more details see: https://www.foonathan.net/2020/10/constexpr-platform/ .

I stand corrected.