For variables, I don't see any reason not to use constexpr
when you can. But it's not always possible to do so, e.g. when the initializer of a variable is computed by a virtual function e.g.
Adding constexpr
to a function is an interface change: you are expressing the fact that you can use it to initialize constexpr
variables. This imposes constraints on the implementation of your function, such as no calling of virtual functions, no dynamic memory allocations and no lambda functions as function objects.
Note that the resolution to LWG issue 2013 does not allow implementers of the Standard Library the freedom to add constexpr
to library functions. One of the reasons is that declaring a function constexpr
can inhibit certain debugging implementations that do dynamic allocations (notably iterator checking). This means that future expansions of constexpr
to the Standard Library need to be separate proposals. This is in contrast to noexcept
, where library writers have more freedom.