C++ Concepts检查成员变量存在性需用嵌套requires或decltype等构造合法表达式，不可裸写T::value；静态与非静态成员检查方式不同，须区分或用||组合；类型约束选same_as或convertible_to依需求而定。
Concepts 要求成员变量存在，不能只靠 requires 检查可访问性
直接写 requires T::value 会编译失败——C++ Concepts 不允许在 requires 表达式中裸写成员名。必须用 decltype 或 std::declval 构造合法表达式，让编译器能推导类型或验证可求值性。
常见错误是试图这样写：
template<typename T>
concept HasValue = requires { T::value; }; // ❌ 错误：T::value 不是表达式
正确做法是把它变成一个能“被求值”的表达式，比如取地址、取类型、或直接使用：
-
requires std::is_same_v<decltype int></decltype>（检查类型+存在） -
requires requires { T::value; };（✅ 最简存在性检查，注意嵌套requires） -
requires requires { { T::value } -> std::convertible_to<int>; };</int>（带类型约束的写法）
用嵌套 requires 检查静态/非静态成员变量最稳妥
静态成员（如 static constexpr int value = 42;）和非静态成员（如 int value;）的检查方式不同，混用会导致 SFINAE 失效或编译器报错。必须区分场景：
立即学习“C++免费学习笔记（深入）”；
- 检查静态成员：
requires { T::value; }即可，因为不依赖对象实例 - 检查非静态成员：
requires(std::declval<t>().value)</t>或更规范地写成requires requires(T t) { t.value; } - 若想同时兼容两者，需拆成两个 concept 并用
||组合，但要注意：T::value和t.value在同一requires块里不会短路，失败时仍会报错
示例（仅要求存在 value 成员，不限定静态/动态）：
template<typename T>
concept HasValue = requires(T t) {
{ t.value } -> std::same_as<int>;
} || requires {
{ T::value } -> std::same_as<int>;
};
std::same_as 比 std::convertible_to 更严格，选哪个看需求
如果你只要求成员能转成 int（比如 short value 也接受），用 std::convertible_to<int></int>；如果必须是 exactly int 类型（含 cv 限定），就得用 std::same_as<int></int>。
-
{ T::value } -> std::convertible_to<int></int>：允许const int、volatile int、short、long等可隐式转为int的类型 -
{ T::value } -> std::same_as<int></int>：只接受签名完全匹配的int（不含引用、不含 const，除非你显式写const int） - 注意：
std::same_as<const int></const>和std::same_as<int></int>是不同的概念，别漏掉const修饰符
模板函数中使用时，别忘了转发引用和 noexcept 一致性
定义好 concept 后，函数签名看似简单，但实际调用时容易因值类别丢失引发问题。比如：
template<HasValue T>
int get_value(T&& t) { return t.value; }
这看起来没问题，但如果 T 是 const 类型，而 value 非 const 成员，就会编译失败。更健壮的写法是：
- 用
decltype(auto)保持返回值类型精确：decltype(auto) get_value(T&& t) { return static_cast<t>(t).value; }</t> - 若函数逻辑不抛异常，加上
noexcept，但要确保T::value访问本身也是noexcept（多数内置类型满足，自定义类型需手动标注） - 别在 concept 里过度约束——比如加
noexcept检查成员访问，反而会让合法类型被拒，除非业务真有强异常保证要求
真正容易被忽略的是：成员变量访问是否受 private 限制。Concepts 只检查可访问性（accessibility），不关心访问控制语义。如果 value 是 private，且模板函数不在友元上下文中，即使 concept 满足，实例化仍会失败。
