C++26 草案被否，二十八年来头一回

C++26 的国际标准草案，在 10 月 23 日的国家代表团投票里没过。

这是这门语言 1998 年标准化以来，第一次走到最后一步又被退回来。

标准要走好几轮投票，前面是委员会内部的技术表决，最后一关叫 DIS，成员国代表团对着整份草案投一次票。

惯例上走到这一步已经是走过场，没人觉得它会被打回。

结果 10 月 23 日这一关没过，整份草案退回修改。

这一关通过之后还有出版流程，所以它一直是整条链上最稳的一段，此前唯一一次同类情况是 2006 年的 C++/CLI 语言规范。

卡住的地方叫契约编程，英文是 Contracts，做法是给函数写上「进来之前必须满足什么」「出去之后保证什么」，编译器可以按开关检查。

对写业务代码的人来说，它要做的事是把注释里那句「传进来的指针不能为空」变成代码的一部分，参数不合规时按编译选项处理，可以全关、只记录，或者直接中止。

写法长这样，函数参数后面直接挂条件：

cpp 复制代码

int get_value(const std::vector<int>& values, std::size_t index)
pre(index < values.size())
{
    return values[index];
}

下标越界的话，按编译选项处理：可以直接中止，也可以只记录一条违约信息继续往下跑。

返回值也能约，写成 post(result: result >= low && result <= high) 这样，函数体中间还能插 contract_assert 检查某一步是否成立。

要留神一点，契约不是输入校验，用户传进来的数据该判断还得自己判断。

对写库的人来说更有用，条件写在函数签名上，编译器知道哪些判断永远成立，运行时就少做一层检查。

麻烦也在这儿，检查开得越严，优化空间越小，两个目标互相拉扯，方案才一路做到这么复杂。

这个特性 2020 年就成立了专门研究组，做了四五年，2026 年 3 月委员会通过整份草案时，它是包含在里面的。

所以这次不是技术方案临门被否，是政治家一层的投票把它拦下来了。

国际标准是一份完整文件，投一次票，不拆开单项表决。

被否的是整份草案，附带的静态反射、并发执行框架，还有上百个没人有意见的小改进，全部跟着一起等。

反对意见也有正式文件。

三位委员会成员写过一份叫《Contract concerns》的论文，逐条列了对这个方案的不放心。

接下来有两条路。

要么改一改契约的细节重新投票，要么干脆把这个特性拿掉。

不管走哪条，反射和并发框架都得继续等，C++26 的时间表也要顺延。

这门语言不会因此死掉，编译器厂商照旧发版本，存量代码一行都不用改。

只是标准没定稿之前，谁也不能对外宣称自己完整支持 C++26，宣传页上的版本号只能继续挂着。

代价是，等了十几年的反射继续等，「让 C++ 变安全」这件事往后推了至少一个版本周期。

同期 Rust 那边不需要投票，一个版本一个版本地往前走。

对正在选型的人来说，这就是个新理由。

Hacker News 上的讨论：https://news.ycombinator.com/item?id=50360164。

你手上还有多少 C++ 项目，欢迎在评论区说说。

关于我：