The keyword constexpr enforced pretty tight restrictions on functions on its introduction into the C++11 standard. These restrictions were loosened with C++14 and C++20 (most noteworthy):
- C++14 allowed multiple
returnstatements,static_asserts etc. - C++20 allowed
tryandasm
C++23 further softens these restrictions. From what I can see in cppreference, constexpr for functions seems to only have the following meaning left:
- it must not be a coroutine
- for constructor and destructor, the class must have no virtual base classes
- For constexpr function templates and constexpr member functions of class templates, at least one specialization must satisfy the abovementioned requirements.
C++23 even removed the restriction that a constexpr function must be "evaluatable" at compile time for any type in p2448r2. From my understanding this completely removed the idea of a constexpr function to be evaluated at compile time.
Is that it? If so, how is a constexpr function even useful anymore?
What you actually seem to ask is: why not make anything
constexprby default?Because you might want others to not use a function at compile-time, to give you a possibility to switch to a non-constexpr implementation later.
Imagine this:
You see a library function, which you'd like to use at compile-time.
Let's say,
size_t RequiredBufferSize();. If it happens to be constexpr, you can allocate the buffer on the stack, or something like that.You're not sure if it's supposed to work at compile-time, because there's no
constexprin our imaginary language.You try it, and it does work at compile-time. You start using it this way.
Let's say the implementation was
{return 42;}, which isconstexpr.A new version of the library is released, the function no longer works at compile-time (e.g. the size is loaded from a config file).
You complain to the developer, and he argues that the function was never intended to work at compile-time, and you relied on an implementation detail.