constexpr静态成员何时不再具备constexpr属性？

咱们从你给出的代码场景出发，拆解那些会让constexpr静态成员没法在编译期语境中使用的情况：

1. 访问表达式不是常量表达式 #

虽然constexpr静态成员本身是编译期常量，但如果你通过一个非常量表达式的路径去访问它，整个访问表达式就不再是常量表达式，自然没法在if constexpr、模板参数、constexpr变量初始化等需要编译期常量的地方使用。

举个你代码里的例子：

template<typename T>
void f2(T x) {
    T y(x); // y是运行期创建的自动对象，其表达式不是常量表达式
    if constexpr (!y.pred) { // 这里y.pred的访问路径依赖于非常量表达式的y
        std::cout << x.val << std::endl;
    }
}

虽然y.pred语法上等价于T::pred，但由于y是一个运行期对象（表达式不是常量），某些编译器在模板实例化时无法将y.pred推导为T::pred的编译期常量访问，导致这个条件无法满足if constexpr的要求——此时y.pred就没法被当作constexpr使用。

而对比你代码里的C<T>::f()：

void f() {
    if constexpr (!x.pred) { // x是类成员变量，编译器能明确推导为T::pred的别名
        std::cout << x.val << std::endl;
    }
}

这里的x是类的成员，编译器可以明确识别x.pred就是T::pred的别名，因此能将其视为编译期常量，所以if constexpr可以正常工作。

2. 静态成员的类内初始化不满足constexpr要求 #

如果constexpr静态成员的类内初始化表达式不是常量表达式，那它本身就不是有效的constexpr成员。比如：

struct BadStr {
    static constexpr int val = rand(); // rand()是运行期函数，不是常量表达式
};

这种情况下，val的初始化表达式不是编译期常量，编译器会直接报错，它从一开始就不具备constexpr特性。

3. 违反ODR（One Definition Rule）导致的链接/编译问题（C++17前） #

在C++17之前，类内初始化的constexpr静态成员仍然需要在类外进行定义（即使初始化已经在类内完成）：

struct JustStr {
    static constexpr bool pred = false; // C++17前：类内初始化，仍需类外定义
};
constexpr bool JustStr::pred; // 必须加这一行

如果省略了类外定义，当你在需要取地址或者ODR使用的语境中访问pred时，编译器可能无法将其视为constexpr常量，甚至会报链接错误——虽然它语法上是constexpr，但实际无法正常作为编译期常量使用。

4. 模板特化中的覆盖导致非constexpr #

如果你的constexpr静态成员是在模板类中定义的，而某个特化版本将其改为非constexpr，那在使用该特化类型时，这个成员就不再是constexpr：

template<typename T>
struct MyTemplate {
    static constexpr bool pred = true;
};

// 特化版本：将pred改为非constexpr
template<>
struct MyTemplate<std::string> {
    static bool pred; // 不再是constexpr
};

当使用MyTemplate<std::string>时，pred就失去了constexpr特性。

内容的提问来源于stack exchange，提问作者fakedrake