Brotcrunsher
Brotcrunsher

Reputation: 2254

Given C++23 relaxations on constexpr, can't constexpr be the default?

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++23 further softens these restrictions. From what I can see in cppreference, constexpr for functions seems to only have the following meaning left:

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?

Upvotes: 10

Views: 1645

Answers (1)

HolyBlackCat
HolyBlackCat

Reputation: 96106

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.

Upvotes: 13

Related Questions