C++ 创始人 Bjarne 反对 WG21 共识
Herb Sutter: When a language's creator and its owners strongly disagree [pdf]
C++26 的 DIS 投票意外失败，核心原因并非技术细节或流程争议，而是 C++ 创始人 Bjarne Stroustrup 首次公开反对 WG21 关于 contracts 功能的强共识。Herb Sutter 在论文中指出，过去 36 年里，尽管社区对 export、constexpr 等功能存在分歧，但大家始终遵循“不同意但执行”的原则，而这次 Bjarne 认为该设计存在严重安全隐患，导致各国成员体（NBs）选择尊重创始人的判断。这种语言创造者与标准委员会的决裂在 C、JavaScript、Python 等语言发展史上并不罕见，但 C++ 能维持 36 年的一致已属不易。面对这一独特挑战，社区需要重新审视决策机制，寻找既能尊重共识又能回应创始人担忧的前进路径。
导致 DIS 失败的核心决定性问题是：语言的创造者与其所有者之间存在严重分歧。
HN 评论区
145- pornel
Stroustrup 列出的反对意见在我看来相当合理：https://www.stroustrup.com/Contracts_fundamental_flaws.pdf
- StellarScience
这是 Herb Sutter 撰写的一篇写得很好且相当得体的总结。我了解得不够深入，无法确定他所说的“Stroustrup 的反对是 C++26 投票失败而其他提案通过的主要原因”是否正确，但这听起来是 plausible（合理的）。
它还列出了 C++26 未来发展的 6 种可能路径及其优缺点。我认为大致如下：
A. 跳过官方的 C++26 标准，将这些功能推迟到 C++29。
B. 从 C++26 中移除 contracts（契约），然后让标准通过。
C. 说声“请”，然后重新投票。
D. 调整关于虚函数的 contracts 细节，然后重新投票。
E. 将 C++26 作为许多国家的国家标准通过，而不是国际标准。
F. 执行 E，并考虑退出 ISO，转而加入 ANSI/INCITS。
- digitalPhonix
我认为这过分夸大了该事件以及 Bjarne 对 contracts 的立场的重要性。
Bjarne 对 contracts 的反对可能压垮了天平，但毫无疑问，人们对那些半途而废、留给实现者去完善的大型功能越来越感到厌倦（和警惕）（modules，看着你）。
- yakaccount4
我有一段时间没太关注 C++ 了（上次看到的有趣特性是 concepts）。通常我挺喜欢用新特性写的那些怪异、富有表现力的代码高尔夫（code golf）。例如，我曾尝试使用 concepts 来确保矩阵维度与所需操作兼容。实用性不大，但作为一个思想实验还挺有意思的。
但这些提议的 contracts……我真的看不出它们比显式编写自己的 assertions（断言）有什么特别的好处。
我想你可以在声明中看到这些要求，但我敢打赌，花哨的现代 C++ 声明很快就会变得非常冗长，让你读起来精疲力竭。也许在 LLM 时代它们更有用？
- Routine8502
作为一个花了几周时间试图入门 C++（那是 LLM 之前，所以现在可能好点了？）然后因为太困惑而放弃的人，我发现应对多种不同的做事方式非常具有挑战性。我是说，该用哪种指针？该怎么迭代？我肯定有答案，但我发现还是回到 Python，或者在需要时去用 Rust 更容易。
似乎部分担忧在于，这个功能必须在第一次发布时就完美无缺，因为它将永远存在。也许允许功能被弃用然后移除会有所帮助？
但我不确定，我还没写过能存活 36 年的东西，所以也许目前的方法就是最好的！
- kikoreis
路过只是想提一句，Sutter 在这里重申 Bjarne 的立场不仅是对的，他还是我心目中关于硬件性能进步和转向并发执行最具影响力的论文的作者：https://www.cs.utexas.edu/~lin/cs380p/Free_Lunch.pdf
- kazinator
36 年的持续共识并不是好事；这意味着没人对任何事说“不”，你得到的只是一个滚下山坡的又脏又大的雪球。
- socalgal2
我敢肯定我不是唯一一个有这种感觉的人，但我觉得 C++ 已经到头了/完蛋了。我在一个 C++ 代码库中工作，做 C++ 已经超过 20 年了，至少对我来说，大限已至。
1. C++ 是不安全的。Bjarne 一直在做演讲，实际上是在说“完美地使用它，不要犯任何错误，它就是安全的”。这已经没用了。在一个 LLM 能发现并利用每一个错误的时代，所有的 C++ 项目都在苦苦挣扎，继续坚持用 C++ 基本上就是在保证未来会有更多的漏洞。是的，并非每个 bug 都能通过切换到更安全的语言来解决，但在新的现实下减少攻击面已不再是能无限期推迟的事情。
2. LLM 可以重写代码。以前的论点是“有 C++ 遗留代码库，所以 C++ 永远不会死”。在 LLM 出现之前，这是一个有效的论点。但 LLM 会直接重写这一切。我知道人们会说 LLM 不完美，但人类也不完美。而且它们一直在进步，我们也看到了它们的进展。人们把 LLM 指向某个项目，它就能神奇地让它在其他平台上运行等等……很明显，这一切正在发生。