Hacker News Reader

Comment by gpderetta | Hacker News Reader

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.

View on HN

I see -fconstexpr-depth, -fconstexpr-cache-depth, -fconsexpr-fp-except, -fconstexpr-loop-limit, and -fconstexpr-ops-limit, but not -fconstexpr: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/C_002b_002b-Di...

Where'd you see -fconstexpr?

Sorry. It is -fimplicit-constexpr, new in gcc12: https://gcc.gnu.org/gcc-12/changes.html

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.

Yes sorry, I should have been more precise.

Of course you need the function body to actually do comptime evaluation.

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.

The problem is that constexpr already is not sufficient to guarantee that.

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.

Reply on news.ycombinator.com