4 ms·
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-
by gpderetta 4y ago
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.
- nynx 4y agoThis 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.
- gpderetta 4y agoThe problem is that constexpr already is not sufficient to guarantee that.
- cbsmith 4y agoHow so? constexpr doesn't guarantee that an expression is evaluated at compile time, but it does guarantee that it could be.
- jcelerier 4y ago> 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
- cbsmith 4y agoYup. Turns out, I was wrong.
- gpderetta 4y agoThat'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/ https://www.foonathan.net/2020/10/constexpr-platform/ .
- cbsmith 4y agoI stand corrected.
- cbsmith 4y agoI 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-Dialect-Options.html#C_002b_002b-Dialect-Options https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/C_002b_002b-Di... Where'd you see -fconstexpr?
- gpderetta 4y agoSorry. It is -fimplicit-constexpr, new in gcc12: https://gcc.gnu.org/gcc-12/changes.html https://gcc.gnu.org/gcc-12/changes.html
- cbsmith 4y agoSo 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.
- gpderetta 4y agoYes sorry, I should have been more precise. Of course you need the function body to actually do comptime evaluation.