It is possible that constexpr keyword for functions will soon go the way of the dodo^Wregister keyword. It is was a pointless keyword added to just to get comp-time evaluation proposal get through the approval process and the the authors have already apologized for it multiple times.
GCC has already added -fconstexpr to implicitly mark all functions as constexpr.
So that doesn't implicitly mark all functions as constexpr. It implicitly marks inline functions as constexpr. It weakens your point a tad, but I see now what you are getting at.
This seems like it could cause issues. Being able to evaluate at compile time is part of the api surface of a function. If it’s not explicit, it could be very easy to accidentally change the internals of a library to not support consteval, but without changing the explicit signature.
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
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.
GCC has already added -fconstexpr to implicitly mark all functions as constexpr.