Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: