复合要求写作 {expr} -> Concept，用于检查表达式合法性及返回类型是否满足概念约束，如 std::same_as 或 std::convertible_to，不可直接写 -> int，因裸类型非概念。
compound requirements 怎么写返回类型检查
复合要求（compound requirement）在 requires 子句里用来验证表达式是否合法、且其结果满足特定约束，比如返回类型是某个类型或可转换为某类型。核心不是“获取返回类型”，而是“断言该表达式求值后满足类型条件”。
语法形如：{ expr } -> ReturnType 或更常见的 { expr } -> std::same_as<t></t>。注意：这里 ReturnType 不能是裸类型名（如 int），必须是概念（concept）或使用标准库提供的类型关系概念。
-
{ *iter } -> std::convertible_to<int></int>：检查解引用后能隐式转成int -
{ container.size() } -> std::same_as<size_t></size_t>：要求返回值类型严格等于size_t -
{ func(x) } -> std::integral：要求返回类型是任意整型（C++20 概念）
为什么不能直接写 -> int
因为 requires 子句中的返回类型约束必须是可求值的概念（即接受一个类型作为参数并返回布尔常量表达式），而裸类型 int 不是概念，编译器会报错：error: expected concept-name。
常见误写：{ f() } -> int → 错误；正确写法必须包裹在概念中：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 精确匹配用
std::same_as<int></int> - 允许隐式转换用
std::convertible_to<int></int> - 只要是有符号整数，可用
std::signed_integral
这些概念定义在 <concepts> 头文件中，漏包含会导致未定义行为或编译失败。
如何检查返回类型是否可默认构造或支持比较
复合要求本身只管表达式合法性 + 返回类型约束，不直接检查返回类型的属性。若需进一步约束返回类型的性质，得拆成多个要求项：
- 先用复合要求确认表达式存在且返回类型满足基础类型条件：
{ x.foo() } -> std::movable - 再额外加独立要求检查该类型的其他性质：
requires std::default_constructible<decltype></decltype> - 或者合并在嵌套
requires中：requires std::movable<decltype> && std::equality_comparable<decltype></decltype></decltype>
注意：decltype(x.foo()) 在 requires 子句外不可用，所以不能在复合要求里写 decltype；所有类型推导必须靠 {...} -> Concept 或顶层 requires 表达式完成。
容易忽略的求值时机和副作用
复合要求中的表达式 { expr } **不会真正执行**，只是进行语义分析（SFINAE 友好），所以即使 expr 有副作用（如调用带打印的函数），它也不会运行。但它的重载解析、模板实参推导、返回类型计算全部发生——这意味着如果 expr 依赖未定义行为或不完整类型，仍会触发编译错误。
- 别在
{ }里放可能 SFINAE 失败但你又没兜底的调用，比如{ T::static_func() }而T可能没这个静态成员 - 避免依赖 ADL 的表达式（如
{ begin(c) }）在未引入对应命名空间时静默失败；建议显式限定或配合using std::begin - 若表达式含模板参数推导（如
{ f(t) }），确保t类型足够明确，否则可能因推导失败导致整个 requires 判定为假
最易被绕过的点：你以为在检查返回类型，其实第一步就卡在表达式是否可形成上——先确保 expr 语法合法、重载可选，再谈返回类型约束。
