3 ms·

I disagree that consteval is what constexpr should have been. It's great to have a function that can work both at compile time and at runtime. `std::max` being

I disagree that consteval is what constexpr should have been. It's great to have a function that can work both at compile time and at runtime. `std::max` being a simple & obvious such example. You of course need that at runtime, that's the classic verison. But why shouldn't it be able to happen at compile time? That's a silly restriction. And thus 'constexpr' - it can run in both modes, depending on when & where it's called. 'consteval' then is for when it must happen at compile time, which is a rather narrow (but very useful!) subset of constexpr. Now, what is silly is that `if constexpr` is only allowed to happen at compile time. That should have been `if consteval` instead, the ordering of these additions is unfortunately reversed.

maldev 4y ago
The issue is that it took 7 years for consteval to be added. Constexpr is extremely prone to "Silent" bugs, where you may mistype it or do something not allowed in a constexpr, the compiler builds it, and it's never actually compile time. It doesn't tell you, it doesn't warn you, it's just never going to be compile time since it's not valid. consteval fixes this by being "Must be compiletime". In my view, it's as if we only had template arguments and now they finally added actual arguments. It should be explicit on what the program is going to put out, especially in a language like C/C++. When you're writing code close to the metal, you need to make sure it's exactly what you wrote. It may be a target platform difference, since I don't use the STL and mainly using C++ language features to target extremely low level devices or goals. In an application dev environment, I can see how constexpr "doing it for you" is fine, but the fact they only had one and not the other is a travesty and has so many footguns. For example, I wrote a DRM program that required an additional buildstep to yell at the developer if they exposed strings or confidential information in the binary. This is solved by consteval, which should've been in there since the beggining.
- kllrnohj 4y ago
  You could always know if a function was compile-time or not based on the usages. Eg, static_assert the output or put it in a constexpr value, and it's guaranteed to be compile-time evaluated or it didn't compile. consteval is helpful in iterations during development to catch that, and I like it as such, but it's definitely not a constexpr replacement nor what constexpr should have been. It's a very small subset of constexpr usages.
JonChesterfield 4y ago
The proper annotation for a function that can run at runtime or compile time is unannotated.
- kllrnohj 4y ago
  Not in C++ it isn't. If you want to change the spec to allow that go for it. But skimming eg. Zig where that's the case, it's also quite non-obvious from the docs if you can know if a function can be used in a comptime statement or not. `constexpr` makes "you can use this at compile time" an explicitly documented attribute of the function, instead of just a guess or by needing to read the implementation.

maldev 4y ago

The issue is that it took 7 years for consteval to be added. Constexpr is extremely prone to "Silent" bugs, where you may mistype it or do something not allowed in a constexpr, the compiler builds it, and it's never actually compile time. It doesn't tell you, it doesn't warn you, it's just never going to be compile time since it's not valid. consteval fixes this by being "Must be compiletime". In my view, it's as if we only had template arguments and now they finally added actual arguments. It should be explicit on what the program is going to put out, especially in a language like C/C++. When you're writing code close to the metal, you need to make sure it's exactly what you wrote. It may be a target platform difference, since I don't use the STL and mainly using C++ language features to target extremely low level devices or goals. In an application dev environment, I can see how constexpr "doing it for you" is fine, but the fact they only had one and not the other is a travesty and has so many footguns. For example, I wrote a DRM program that required an additional buildstep to yell at the developer if they exposed strings or confidential information in the binary. This is solved by consteval, which should've been in there since the beggining.

kllrnohj 4y ago
You could always know if a function was compile-time or not based on the usages. Eg, static_assert the output or put it in a constexpr value, and it's guaranteed to be compile-time evaluated or it didn't compile. consteval is helpful in iterations during development to catch that, and I like it as such, but it's definitely not a constexpr replacement nor what constexpr should have been. It's a very small subset of constexpr usages.

JonChesterfield 4y ago

The proper annotation for a function that can run at runtime or compile time is unannotated.

kllrnohj 4y ago
Not in C++ it isn't. If you want to change the spec to allow that go for it. But skimming eg. Zig where that's the case, it's also quite non-obvious from the docs if you can know if a function can be used in a comptime statement or not. `constexpr` makes "you can use this at compile time" an explicitly documented attribute of the function, instead of just a guess or by needing to read the implementation.