c++26的Circle元编程语法(P2590)会带来什么？ (简化TMP)
C++26 并不存在名为“Circle”的元编程语法；P2590R0 是关于 std::meta 反射 TS 的标准提案，而 Circle 是第三方非标编译器及其私有扩展，二者无隶属关系。C++26 的
Circle 元编程语法（P2590）目前并不存在——它不是已通过、已合并、甚至未进入 TS 的标准提案。
P2590R0 标题是 “std::meta: A Reflection TS for C++26”，它提出的是基于反射（reflection）的元编程设施，而非名为 Circle 的语法。所谓 “Circle” 实际来自第三方编译器 Circle（由 Sean Baxter 开发），它是一个实验性 C++ 前端，自带一套非标准、高度激进的元编程扩展（包括 __meta、__if、__for 等关键字），但这些**完全不属于 ISO C++ 标准**，也不在 P2590 中。
为什么你会看到 “Circle + P2590” 混在一起？
常见混淆点有三个：
- Circle 编译器作者曾用其原型实现过类似 P2590 设想的反射能力，导致部分博客/推文把二者混谈
- P2590 提议的
std::meta::info、std::meta::get_name等 API，在 Circle 中有同名但语义不同、行为更激进的对应物（如__name_of） - 某些中文技术社区将 “Circle 的元编程” 误标为 “C++26 新特性”，再套上 P2590 编号，造成传播失真
P2590R0 真正带来的变化（面向标准 C++ 用户）
它若被采纳，将是 C++ 首次引入**可移植、编译期可用的结构化反射**，核心不是新语法糖，而是新类型与契约：
-
std::meta::info是一个不透明的编译期值类型，代表任意声明（类、函数、成员等）的反射信息 - 所有反射操作都是纯函数式：例如
std::meta::get_members(info)返回std::meta::info_sequence，而非宏或模板特化 - 不依赖
constexpr函数模拟反射（像std::is_same_v那种），而是直接暴露 AST 层信息 - 无运行时开销：所有反射数据在编译期求值，不生成额外符号或 RTTI
// P2590 草案风格（非最终语法） constexpr auto cls = std::meta::reflect; for (auto m : std::meta::get_members(cls)) { if (std::meta::is_data_member(m)) { constexpr auto name = std::meta::get_name(m); // 编译期字符串字面量 } }
Circle 编译器的 __meta 扩展不能当 C++26 用
如果你在代码里写了 __meta::for_each_member 或 __if (__is_class(T))：
- 这些在 GCC/Clang/MSVC 下直接报错：
unknown type name '__meta' - 它绕过了模板系统，允许在非模板上下文中写元循环，但牺牲了可移植性与诊断质量
- 它的“简化 TMP”是以放弃标准兼容为代价的——你写的不是 C++，是 Circle-C++ 方言
- 即便 P2590 最终落地，其设计原则是“最小侵入、最大可预测”，不会引入
__前缀关键字或隐式展开
Circle 的语法降临；它会靠 std::meta 这类标准库设施，配合已有 constexpr、template 和 Concepts 渐进演进。现在就依赖非标扩展，等于主动把自己锁进单编译器生态——而最常被忽略的一点是：P2590 的反射对象本身不可序列化、不可跨 TU 传递，连 constexpr 函数参数都受限，远比表面看起来更谨慎。
