C++26 因 Contracts 争议在最后阶段受阻

ISO 工作组因运行时检查、复杂度以及语言发布时间表陷入争执

由于围绕一项增强安全性的 Contracts 特性存在争议，C++ 编程语言的下一个版本可能在最后一刻被推迟。

Contracts 已使 C++ 技术维护者严重分裂。一方支持 C++ 的创造者 Bjarne Stroustrup，他反对该技术以目前的形式存在，理由是它实施仓促。但另一方则急切希望看到 Contracts 落地，甚至认为该技术的批评者是在毒害 C++ 的开发流程本身。

这场分歧在就批准该语言新版本进行投票前夕彻底爆发。

今年 10 月，C++26 的国际标准草案（DIS）未能通过 ISO 投票——这是国际标准化组织审批流程中的倒数第二阶段，在此期间，一项标准的技术细节由各国家标准化机构正式批准。

投票结果为 13 票赞成、9 票反对、12 票弃权，未能满足 ISO 关于反对票不得超过 25% 的要求。Contracts 是投反对票者的主要症结所在。

Contracts 允许开发者向代码添加前置条件和后置条件，以及用于检查指定条件是否成立的断言。此类检查有助于捕获那些原本可能导致未定义行为的编程错误。

契约式设计长期以来一直是 Ada 和 Eiffel 等语言的一项特性。

开发者们提出为 C++ 添加 Contracts 至少已有十年之久，此前该特性因对危险默认值的担忧而被突然从 C++20 中移除。

但 Stroustrup 猛烈抨击了最终进入 C++26 的修订提案（P2900）。

“P2900 的 contracts 及其扩展旨在改变 C++ 的本质，对 C++ 构成生存威胁，增加了复杂性和臃肿，”Stroustrup 及其同事在去年八月的一篇论文中写道。他们指出，该实现混乱、过时、测试不充分，并且作为库来实现可能更有效。

并非所有人都同意。C++ 标准委员会成员 Andreas Fertig 认为，这些批评已经过审查，在 C++ 发布流程如此靠后的阶段否决该提案，对 C++ 本身是有害的。

“这个议题已经研究了多年，并且以其当前形式多次获得多数票。通过投‘反对’票，一个既定的体系——一个主要基于信任和相互尊重协作的体系——已经受到动摇，”Fertig 在一篇博客文章中写道。

当然，显而易见的问题是，人们持续批评开发者很容易在 C++ 中意外制造安全漏洞，导致不少项目转而采用 Rust。正如 Stroustrup 所指出的，添加控制措施可能会损害 C++ 作为一门极速语言的核心属性。

Fertig 指责 Stroustrup 及其同僚是输不起的人。

“每一项 ISO 标准都只是一系列妥协。每个人有时会输，每个人有时会赢，”他写道。但在这种情况下，“输的一方拒绝接受失败。决定如何向前推进的首要问题是，该小组能否重建信任。”

与 Fertig 不同，C++ Alliance（维护开源 EDG C++ 编译器前端）的 CEO Harry Bott 并不认为 Contracts 的讨论对 C++ 本身具有破坏性。

“被退回的草案并不是流程的失败——而是流程在按预期运作，”他在给 The Register 的电子邮件中写道。“这并不意味着流程不能改进。目标应该是从中吸取教训并加强流程，使 C++ 能够继续以开发者可以依赖的方式演进。”

由于投票在标准化流程如此靠后的阶段失败——这在 C++ 历史上实属罕见——该语言面临错过今年预期发布日期的风险。这一结果可能迫使所有人将新版本称为“C++27”而非 C++26。（这只是非正式名称；如果该语言的第八个版本于明年发布，其官方名称将是“ISO/IEC 14882:2027”。）

ISO C++ 工作组 WG21 将于下周在巴西布齐奥斯举行会议，进行最终对决。

据巴黎 Margo 咨询公司的软件工程顾问 Thibault Ricord-Marchal 的一篇博客文章称，该小组面临多种选择。

他们可以将 Contracts 从规范中剥离，以便 C++26 的其余部分能够发布。不过，这将是棘手的工作。必须对已经使用 Contracts 完成的许多库加固工作按下撤销键。

另一个选择是将 Contracts 移入单独的技术规范，在那里可以继续完善该技术。

或者他们可以进行一次小幅修订，再次投票，并希望巴西温暖的气候能让所有人冷静下来。®