带模板IIFE的静态constexpr数据成员未检查requires子句咨询

问题场景 #

以下代码中，用不满足IsIncrementable约束的std::vector<int>实例化Test模板时，编译不会报错，只有当直接访问静态成员a时才触发错误：

#include <vector>

template <typename T>
concept IsIncrementable = requires(T a) {
    ++a;
};

template<typename T>
struct Test
{
    static constexpr int a = [](auto x) -> int requires IsIncrementable<T> { return 0; }(0);
};

int main()
{
    // 此处编译通过，不符合预期
    Test<std::vector<int>> t;
    // 只有访问a时才会报错：Test<std::vector<int>>::a的初始化表达式违反requires约束
    // Test<std::vector<int>>::a;
    return 0;
}

问题解答 #

1. 标准是否允许不检查该requires子句？ #

允许。类模板静态constexpr成员的初始化逻辑属于延迟实例化范畴，编译器不需要在类模板实例化阶段就检查requires约束。

2. 是否仅在变量被使用时才检查？ #

是的。只有当静态成员a被ODR使用（如直接访问、取地址、作为函数参数传递等）时，编译器才会处理其初始化表达式，此时才会触发lambda的operator()实例化，进而检查requires约束。

3. 标准对应章节 #

根据C++20标准：

• [temp.inst]/2：类模板实例化时，只会实例化类的声明部分，不会实例化类成员的定义（包括静态成员的初始化表达式），除非该成员被ODR使用。
• [expr.prim.lambda.closure]/5：带auto参数的泛型lambda，其operator()是一个模板函数，模板函数的约束检查会延迟到该函数被实例化时（即初始化表达式被求值时）。

4. auto关键字在此处的特殊作用 #

auto参数让lambda成为泛型lambda，其operator()是模板函数。requires子句附加在这个模板函数上，而模板函数的约束检查遵循延迟实例化规则。如果没有auto，lambda的operator()是非模板函数，标准不允许给非模板函数添加requires子句（GCC/Clang的编译通过属于非标准扩展）。

5. 此处用IIFE初始化是否有特殊之处？ #

IIFE本身只是立即调用lambda，但因为lambda是泛型的，其operator()的实例化被延迟到静态成员被ODR使用时。如果不用IIFE，直接将lambda赋值给a（如static constexpr auto a = []() requires IsIncrementable<T> { return 0; };），行为类似——只有当a被使用时才会检查约束。这里用IIFE是为了直接获取int值，但初始化的延迟特性让调用也被推迟了。

6. 在此上下文中使用IIFE是否合法？ #

合法。C++允许在常量表达式中调用constexpr lambda（此处lambda满足constexpr要求，返回值是常量表达式），只要调用时满足所有约束。只是因为静态成员的初始化延迟，IIFE的执行（包括约束检查）被推迟到ODR使用阶段。

补充实验分析 #

• MSVC的表现差异：MSVC在类模板实例化时就提前检查了静态成员的初始化表达式，这属于编译器实现的差异，不符合标准的延迟实例化规则。
• 改为static constexpr auto a的效果：auto需要推导类型，编译器必须立即实例化lambda的operator()来确定返回类型，因此会触发requires检查，导致实例化失败，符合预期。
• 移除x后的编译通过：GCC/Clang允许给非模板函数加requires子句，这是编译器的非标准扩展，不符合C++标准要求。

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