Why must non-integral static data members initialized in the class be constexpr?

Question

Static integral data members initialized in the class definition may be declared const or constexpr, but non-integral static data members initialized in the class definition must be constexpr:

class MyClass {
  static const     int   w = 5;          // okay
  static constexpr int   x = 5;          // okay
  static const     float y = 1.5;        // error!
  static constexpr float z = 1.5;        // okay
};

Does anybody know why the declaration for y is not permitted? The part of the Standard making it illegal is 9.4.2/3, but why is it illegal?

Answer 1

Prior to C++11, you could not initialize static members of non-integral/enumeration types in the class declaration (but you can outside of the class declaration). The rule governing constexpr carries that forward, but allows you to initialize it using constexpr in the class declaration (so you don't need code like the following anymore):

struct A
{
    static const float pi;
};

const float A::pi = 3.1415;

One of the side effects of this rule was to simplify your class structure instead of making it ugly (like the above code).

One of the reasons why this was the case prior to C++11's addition of constexpr was the standard did not specify how floating points were to be implemented (it is left to the processor/architecture - for example, when you say float x = 1.6f, it is actually 1.6000000000024 on most systems).

Answer 2

float is a bit of a harder one to describe the motivation for, but imagine a class member:

class MySpecialInt {
public:
    constexpr MySpecialInt(const int & other) {
    }
};
class MyClass {
    static const     MySpecialInt a = 5; // error
    static constexpr MySpecialInt b = 5; // okay
};

a in this scenario could have some non-trivial construction that potentially violates (or at least grossly complicates) the one-definition-rule. Because constexpr has guaranteed restrictive compile-time properties, b's copy constructor must also be constexpr and is therefore guaranteed to return a well defined value at compile-time (and NOT violate the one-definition-rule)

Why float exhibits this behavior I believe is just for legacy reasons since float has never been traditionally initialize-able like this ("because the standard says so"), so they caught initializing static const float members under the umbrella of constexpr.