本文永久链接 – https://tonybai.com/2026/11/09/cpp26-historic-dis-rejection-herb-sutter

大家好，我是Tony Bai。

【导读】

C++26 遭遇了一次载入语言标准化历史的挫折。

2026 年 10 月 23 日，经过为期 12 周的国际投票，C++26 的最终国际标准草案（DIS）未能获得通过。据参与标准化工作的委员披露，这是 C++ 历史上首次出现这样的情况。

更戏剧性的是，这场风波的核心，竟然是 C++26 新增的一项语言特性——Contracts（契约）。

投票失败后，C++ 标准委员会的重要人物 Herb Sutter 发布了一篇文章，标题相当耐人寻味：

When a language’s creator and its owners strongly disagree: C++26 post-DIS, historical experience, and paths forward

翻译过来就是：

当一门编程语言的创造者与它的所有者发生严重分歧时：C++26 投票失败后的历史经验与未来出路。

这里的语言创造者，指的是 Bjarne Stroustrup，也就是 C++ 之父。

这已经不再是简单的技术争论，而是涉及一门成熟编程语言究竟应该由谁来决定其未来的问题。

【文章要点】

  • C++26 的 DIS 投票为什么如此特殊？
  • Herb Sutter 的文章究竟提出了什么问题？
  • Bjarne Stroustrup 与标准委员会之间的分歧是什么？
  • ISO 标准制定机制与 C++ 社区治理之间存在什么张力？
  • C++ 过去遇到类似危机时，是如何解决的？
  • 这场争论对 C++ 的未来意味着什么？

C++26，为什么突然被 ISO 否决了？

先说一个背景。

C++ 标准并不是由某个公司或者某个人直接拍板发布的。

它背后有一套复杂的国际标准化流程。

负责 C++ 语言标准制定的工作组是 ISO/IEC JTC1/SC22/WG21，通常简称 WG21。

我们熟悉的 C++11、C++14、C++17、C++20、C++23，都是通过这套机制逐步形成并最终发布的。

一份新标准在正式发布之前，需要经过多个阶段。其中，DIS（Draft International Standard）是非常靠后的一个阶段。

简单来说，DIS 就是提交给 ISO 成员国进行最终审查和投票的国际标准草案。

按照 ISO 的投票规则，DIS 需要满足两个条件：

  • 至少三分之二的参与投票的 P 成员国投赞成票。
  • 反对票不能超过全部投票成员的四分之一。

2026 年 10 月 23 日，C++26 的 DIS 投票结束。

结果：Disapproved！

这是一次极为罕见的结果。

据 C++ 标准委员会成员 Andreas Fertig 的调查，在他能够查到的 ISO 编程语言标准记录中，除了 2006 年未获通过的 C++/CLI 标准草案之外，很难找到类似先例。而 C++/CLI 项目最终被终止。

这意味着，C++26 遇到的并不是普通的标准化流程延迟，而是一次真正的国际标准投票失败。

需要强调的是，ISO 并未公开各国的具体投票明细。网上流传的具体票数属于参与者或其他渠道披露的信息，不能当作 ISO 官方公布的完整统计。

那么，究竟是什么让 C++26 在最后关头翻了车？

答案是：Contracts。

一项 Contracts 特性，为什么引爆了整个 C++26？

Contracts，中文通常翻译为契约。

它的核心思想并不复杂：让程序员能够在函数接口层面表达前置条件、后置条件以及断言。

例如：

int divide(int a, int b)
    pre(b != 0)
{
    return a / b;
}

这里的 pre(b != 0) 表达了一个前置条件：调用者必须保证除数不为零。

与传统的 assert 相比，Contracts 希望提供更加系统化、标准化的机制，让函数接口中的约束成为语言的一部分。

这项特性并不是 C++26 临时塞进去的新玩具。

事实上，C++ 社区围绕 Contracts 已经讨论、设计和争论了很多年。

最终进入 C++26 的设计，来自提案 P2900 及其后续修订。

支持者认为，Contracts 可以帮助开发者表达程序的正确性约束，为调试、运行时检查和代码质量提升提供统一机制。

但反对者认为，当前设计还存在一些根本性问题。

而站在反对阵营前列的，恰恰是 C++ 之父 Bjarne Stroustrup。

2026 年 8 月，Bjarne Stroustrup 等人提交了提案：

P4334R0：P2900 Contracts’ fundamental flaws

这份文档直接指出了当前 Contracts 设计存在的根本缺陷。

争议主要集中在几个方面：

1. 设计是否真正成熟？

反对者认为，Contracts 是一项会深刻影响语言语义的基础设施，不应该在缺乏充分实现和大规模实践验证的情况下匆忙进入标准。

2. 不同检查模式带来的语义问题。

Contracts 允许不同的检查模式，例如 ignore、observe 和 enforce。

这些模式在不同编译配置下可能表现不同。

反对者担心，这会给程序行为、跨翻译单元的一致性以及程序员对契约语义的理解带来复杂性。

3. 关键能力还没有得到充分解决。

包括契约检查的保证机制、虚函数相关语义，以及一些关键设计细节。

反对者认为，不能把尚未解决的问题简单推迟到未来版本。

这背后其实存在两种不同的工程哲学：

一方希望先将一个经过多年讨论的实用方案纳入标准，再通过后续迭代完善。

另一方则认为，Contracts 这样的基础语言设施一旦进入标准，就可能影响未来几十年的代码，必须在发布前充分验证。

这不是简单的喜欢与不喜欢，而是对语言长期演进风险的不同判断。

真正的冲突：委员会内部通过了，为什么国际投票却失败了？

这里才是整个事件最值得关注的地方。

2026 年 3 月，WG21 在英国 Croydon 举行的会议上完成了 C++26 的技术工作。

Herb Sutter 在当时的会议报告中披露，委员会全体会议对是否将 Contracts 保留在 C++26 中进行了投票：

  • 赞成：114
  • 反对：12
  • 弃权：3

最终，委员会决定保留 Contracts，并将 C++26 草案提交给后续国际投票。

从委员会内部的投票结果看，支持者占据明显优势。

然而，到了 ISO 国家成员机构投票阶段，结果却完全不同。

这揭示了一个非常重要的制度事实：

WG21 内部的技术共识，并不等于 ISO 国际标准层面的最终认可。

WG21 负责制定和维护 C++ 标准草案，但最终国际标准的批准权属于 ISO 的标准化程序。

两者并不是同一回事。

而这一次，反对 Contracts 的声音最终在国际投票阶段获得了足以阻止标准通过的支持。

这也让原本已经接近终点的 C++26 陷入僵局。

更重要的是，这场争论并非只有技术层面的分歧。

支持者认为，委员会已经进行了多年讨论、反复投票，并且形成了明确的多数意见。既然按照既定规则完成了决策，就应该尊重结果。

反对者则认为，对于一项尚未成熟的基础语言设施，即使委员会内部形成了多数意见，也不意味着所有重大技术问题都已经得到解决。

双方都在强调程序和工程责任，只是对两者的优先级理解不同。

Herb Sutter 的文章：C++26 究竟还有哪些出路？

投票失败后，Herb Sutter 发布了这篇非常值得阅读的文章：

P4454R0：When a language’s creator and its owners strongly disagree: C++26 post-DIS, historical experience, and paths forward

这篇文章最值得关注的，不只是对争议的回顾，而是它试图回答一个更现实的问题：

现在，C++26 到底应该怎么办？

Herb Sutter 将问题放到了更大的历史背景中讨论：当语言的创造者与负责维护标准的组织出现严重分歧时，应该如何处理？

这里需要区分两个概念。

Bjarne Stroustrup 是 C++ 的创造者，但 C++ 并不属于他个人。

WG21 负责标准的技术演进，ISO 负责国际标准的批准。编译器厂商、工具链开发者和全球开发者则共同构成了 C++ 实际生态。

因此，创造者的意见具有极高的技术和历史分量，却不等于拥有最终决定权。

而标准组织拥有制定标准的制度权力，也不意味着它可以忽视语言设计的长期一致性。

Herb Sutter 的文章围绕这个矛盾，讨论了 C++26 投票失败之后的多种可能路径。

结合文章及其讨论，可以将这些路径归纳为六种：

路径 A：放弃单独发布 C++26，将已完成的工作合并到 C++29。

这意味着 C++26 不再作为一个独立的正式标准发布。

相关特性需要重新进入下一轮标准化流程。

优点是可以避免在争议没有解决的情况下仓促发布。

缺点也很明显：大量已经完成的标准化工作可能被推迟，整个 C++ 演进节奏受到影响。

路径 B：从 C++26 中移除 Contracts，再重新提交投票。

这是一条相对直接的路线。

既然 Contracts 是当前争议的核心，那么将其移除，让其他已经完成的特性继续进入标准化流程。

但问题在于，Contracts 已经与部分标准库强化设计产生了关联。移除它并不是简单删除几段标准文本，还可能需要调整相关设计。

同时，这也意味着支持者需要接受此前已经通过的委员会决策被重新推翻。

路径 C：保留现有设计，争取重新投票。

如果委员会认为原有技术决策仍然成立，可以尝试重新提交修订后的草案，争取获得国际成员机构认可。

但如果没有解决反对者的核心疑虑，仅仅重新投票，很可能只是重复之前的结果。

路径 D：针对 Contracts 的部分争议进行有限修改，再重新投票。

例如，针对虚函数等有争议的语义进行调整。

这样可以尝试在保留 Contracts 主体设计的同时，回应部分反对意见。

但修改范围如何确定、是否足以获得新的共识，都存在不确定性。

路径 E：探索通过不同国家的国家标准体系发布相关内容。

如果国际标准化路径陷入僵局，可以考虑其他国家标准化机制。

但这会带来标准协调和国际认可方面的问题。

路径 F：进一步调整标准化组织路径。

包括讨论是否继续沿用现有 ISO 路线，或者探索 ANSI/INCITS 等其他标准化渠道。

这无疑是最具争议、也最具制度影响的一条路线。

需要说明的是，这些路径是对文章讨论及相关社区讨论的归纳，并不意味着它们都已经成为 WG21 正式通过的决议。

六条路径背后，其实只有一个核心问题：

C++26 应该优先维护已经形成的委员会决策，还是应该优先回应国际投票暴露出来的技术分歧？

这才是这场风波真正难以解决的地方。

这场争论，让我们重新思考编程语言应该如何治理

Hacker News 上，这篇文章也引发了大量讨论。

其中一个非常有意思的话题是：

一门编程语言究竟应该由谁来决定它的未来？

有人认为，语言设计需要一个有明确权威的领导者。

他们举出了 Python 早期 Guido van Rossum 的 BDFL（终身仁慈独裁者）模式，以及 Linux 内核由 Linus Torvalds 主导、逐步形成维护者体系的例子。

这种模式的优势在于，决策链条相对清晰，语言可以保持比较一致的设计方向。

但它也有明显局限：个人的精力、判断和生命周期都有限，如何完成权力交接，也是长期治理必须面对的问题。

另一派则认为，像 C++ 这样拥有庞大生态、众多厂商和数十年历史的语言，根本不可能由某个人决定一切。

它需要委员会，需要公开讨论，需要让不同国家、厂商和技术专家共同参与。

但委员会模式同样存在成本。

决策过程漫长，技术共识难以形成，而且当多数意见与少数重要技术参与者发生冲突时，如何平衡效率与审慎，是一个长期难题。

这次 C++26 的争议，恰好将这些问题集中暴露了出来。

还有一个值得注意的观点：

标准不等于语言本身。

Hacker News 上有参与者指出，ISO 标准定义的是标准化的 C++，而实际开发者使用的 C++，还受到 GCC、Clang、MSVC 等编译器实现以及各自生态的影响。

这提醒我们，标准组织虽然对语言演进具有重大影响，却并不是整个 C++ 生态的唯一参与者。

但反过来，如果缺少统一标准，编译器和平台之间也可能出现越来越严重的分歧。

所以，无论采用个人主导还是委员会治理，都没有绝对完美的答案。

小结：C++ 的未来，真正需要的是重新建立共识

截至 2026 年 11 月 9 日，C++26 的 DIS 投票已经失败，但这并不意味着 C++26 就此终结，更不意味着 C++ 语言本身出现了危机。

ISO 标准化流程仍然提供了重新提交草案、返回委员会草案阶段、发布技术规范以及终止项目等不同处理方式。

下一次 WG21 全体会议计划于 2026 年 11 月 16 日至 21 日在巴西 Búzios 举行。

如何处理 C++26 的国际投票意见，以及如何重新建立委员会内部的共识，将成为会议的重要议题。

对开发者来说，还有一个值得关注的细节：

这次投票针对的是整个 C++26 草案，而不是只针对 Contracts。

因此，Reflection、std::execution、标准库强化等已经进入 C++26 的其他特性，也会受到这次投票失败的影响。

这才是这件事对 C++ 开发生态真正的影响。

我觉得，这次事件最值得思考的并不是 Contracts 到底应该保留还是删除。

而是：

一门已经发展了 40 多年、拥有庞大产业生态的编程语言，如何在保持技术演进速度的同时，确保每一次重大设计决策都经得起长期实践的检验？

C++ 的复杂性，来自它对历史兼容性的承诺，也来自它需要同时满足不同领域、不同厂商和不同世代开发者的需求。

它不可能像一门刚刚诞生的新语言那样轻装上阵。

但也正因为如此，C++ 的每一次标准演进，都需要更高程度的审慎和共识。

这次 C++26 的投票失败，也许会让 C++ 的下一个标准晚一些到来。

但对于一门可能还要服务未来几十年的编程语言来说，有时候，慢下来把问题解决清楚，比按时发布一个存在重大争议的标准更加重要。

参考资料：

  1. Herb Sutter：《When a language’s creator and its owners strongly disagree: C++26 post-DIS, historical experience, and paths forward（P4454R0）》- https://isocpp.org/files/papers/P4454R0.pdf
  2. Hacker News：Herb Sutter: When a language’s creator and its owners strongly disagree - https://news.ycombinator.com/item?id=50418818
  3. Bjarne Stroustrup：P4334R0 — P2900 Contracts’ fundamental flaws - https://stroustrup.com/Contracts_fundamental_flaws.pdf
  4. Andreas Fertig：C++26 DIS failed, how does C++ survive? - https://andreasfertig.com/blog/2026/11/cpp26-dis-failed-how-does-cpp-survive/
  5. Herb Sutter：C++26 is done! — March 2026 ISO C++ standards meeting - https://herbsutter.com/

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

  • 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
  • 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
  • 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

「Go & AI 精进营」已全面升级为「Go, Rust & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 现代系统级开发（Go / Rust） 与 前沿 Agentic AI 工程实践 平台。在这里，你将获得：

  • 体系化 Go 核心进阶内容： 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 语言内功。
  • 硬核 Rust 专项实战赋能： 同步解锁全年 54 讲独家专栏「事不过三：Rust 系统级入门实战课」，通过 4 个里程碑项目（命令行工具、KV引擎、多线程Web服务、异步Redis），带你彻底攻克所有权与并发高山，拿下 Rust 核心壁垒。
  • 前沿 Agentic AI 落地实践： 紧跟时代步伐，系统学习「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战」、「Harness工程设计」等，掌握 AI 时代的系统架构新技能。
  • 星主 Tony Bai 亲自答疑： 遇到疑难杂症？星主第一时间为你深度解析，扫清 Go、Rust 与 AI 实践中的学习与工程障碍。
  • 高活跃 Gopher & Rustacean 交流圈： 与众多优秀的技术极客探讨系统设计、分享前沿心得、碰撞思想火花。
  • 独家资源与专栏首发： 博客深度长文、专栏教程更新、精选技术资源，星球会员第一时间触达，加入星球即可免费阅读全套进阶专栏！

衷心希望「Go, Rust & AI 精进营」能成为你拓宽技术边界、持续精进与交流的温暖港湾。让我们在此相聚，享受代码与工程之美以及技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。