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 return statements, static_asserts etc.
• C 20 allowed try and asm

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?

CodePudding user response：

What you actually seem to ask is: why not make anything constexpr by 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 constexpr in 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 is constexpr.

• 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.