4 ms·

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 e

by nynx 4y ago

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.

gpderetta 4y ago
The problem is that constexpr already is not sufficient to guarantee that.
- cbsmith 4y ago
  How 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 ago
      Yup. Turns out, I was wrong.
  - gpderetta 4y ago
    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/ https://www.foonathan.net/2020/10/constexpr-platform/ .
    - cbsmith 4y ago
      I stand corrected.

by nynx 4y ago

gpderetta 4y ago

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

cbsmith 4y ago
How 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 ago
    Yup. Turns out, I was wrong.
- gpderetta 4y ago
  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/ https://www.foonathan.net/2020/10/constexpr-platform/ .
  - cbsmith 4y ago
    I stand corrected.